Re: Re: [Csnd] csound software idea, looking for partners

abez <[email protected]> Sat, 17 Jul 2004 01:56:14 -0700 (PDT)
Newsgroups gmane.comp.audio.csound.tekno
Message-ID <[email protected]>
It simply sends text through pipes. I have a modified CSound which
accepts UDP messages which works very well for decoupling the GUI from
Csound.

abram

On Sat, 17 Jul 2004, iain duncan wrote:

> Abram, how do your gui systems send messages to csound? Is it just text 
> out pipes or is there more to it?
> 
> Hopefully the CsoundAPI will make getting feedback *from* csound easier 
> in the future. = )
> 
> Iain
> 
> > I have made 2 gui systems for CSound. 1 is EventGUI a java based Gui
> > Framework for controlling CSound instruments during performance.
> > The 2nd is FastGUI an SDL::Perl based Gui Framework for controlling
> > CSound instruments during a performance. FastGUI is effectively a widget
> > set designed for realtime performance purposes.
> > 
> > EventGUI should be available from http://skruntskrunt.abez.ca/ it uses
> > an XML definition of a GUI for display and is the easiest to use.
> > 
> > FastGUI requires a good knowledge of OO Perl right now and is much
> > faster and better than EventGUI but harder to use. You'll have to email
> > me to get a copy of the source code.
> > 
> > With the GUI there is little concern for resources you'll find. As long
> > as you set the priority of the GUI processes lower than that of the
> > rendering engine you'll be fine.
> > 
> > See:
> > 
> > http://abez.ca/supernaut/oopsla.pdf
> > http://abez.ca/supernaut/oopsla.out.pdf
> > 
> > You have pointed one problem of GUIs for CSound, feedback to GUI. It is
> > a difficult problem.
> > 
> > abram
> > 
> > On Thu, 15 Jul 2004, iain duncan wrote:
> > 
> > 
> >>>I think you could write your app entirely in Python, just using the
> >>>existing C++ Csound API. I suggest you use Boa Constructor, which is a
> >>>graphical form editor for wxPython GUIs, to design your screens.
> >>
> >>This sounds like it would be worth a shot too. How is Boa Constructor in 
> >>comparison to Fluid? Maybe it would be worthwhile to have a couple of 
> >>examples, one in C++, one in python. One obvious advantage of the 
> >>C++/fltk, as I see it, is that one could make a small fast statically 
> >>linked standalone csound instrument/app with gui without needing python 
> >>installed or the runtime overhead of Python. Disadvantage is harder to 
> >>write I guess.
> >>
> >>Also, I have a better idea than an ear training app for a small embedded 
> >>csound gui demo. I was thinking that something very useful would be a 
> >>generic virtual controller surface in which sliders and buttons send 
> >>values directly to csound tables or output values as score events, with 
> >>the output being adjustable from the app. So say there were sixteen 
> >>widgets on screen for example, you might have a tab that allows the user 
> >>to change which table and index each slider goes to and which score 
> >>events the buttons send, along with the ability to save snapshots of the 
> >>configuration and the current values. One could also add the ability to 
> >>save the snapshot as a text file suitable for loading in csound using 
> >>gen23. This could be a great way to tweak table based instruments in 
> >>real time and save the values, and just a generally handy way to make 
> >>low overhead low priority gui controllers for real time use. It would 
> >>also mean that users who don't want to jump into building their own guis 
> >>from scratch could use say a 64 knob 64 button generic example and just 
> >>configure it themselves without having to write C++.
> >>
> >>I see no reason the sliders could not also be made to receive midi input 
> >>for remote control.
> >>
> >>I am thinking fltk for C++ and taking Michael's suggestions for python. 
> >>Anyone have good reasons to do otherwise? How does GTK compare to fltk 
> >>for this kind of stuff?
> >>
> >>For myself, being a newbie, my first steps will be small. I plan to 
> >>spend the next little while just trying to make a gui with a couple of 
> >>buttons that send an event to embedded csound5. If anyone wants to help 
> >>or is willing to act as an advisor/tutor please let me know.
> >>
> >>Thanks
> >>Iain
> >>
> >>
> >>
> >>>Original Message:
> >>>-----------------
> >>>From: iain duncan [email protected]
> >>>Date: Wed, 14 Jul 2004 03:19:39 +0000
> >>>To: [email protected]
> >>>Subject: Re: [Csnd] csound software idea, looking for partners
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>>Why c++ though? Why not just python and c. You
> >>>>probably could do everything you want to do just using
> >>>>python and csounds. The python gui could just write in
> >>>>midi to /dev/midi or something. There are already
> >>>>python modules the read and write midi. Well, since
> >>>>*nix is the only platform that uses device files it
> >>>>would not be very cross platform if you did it that
> >>>>way I suppose.  
> >>>
> >>>
> >>>Perhaps I didn't make myself as clear as I thought. What I intend is not 
> >>>a comprehensive ear training app for linux, but a small tweakable ear 
> >>>training app as an example of an app that embeds csound and uses csound 
> >>>as it's audio engine. So the app would communicate with csound via the 
> >>>csound API and not require any midi at all.
> >>>
> >>>I was planning on using C++ because Michael suggested that as the best 
> >>>way to use the API, and I could do with a simple C++ project too. My 
> >>>thoughts about python are just brainstorming, I'm not sure how practical 
> >>>that would be. I just kinda figured it would be cool to be able to let 
> >>>the users write their own drills in some kind of scripting language. ( 
> >>>The way you can use CAL from cakewalk for example, or python in GVIM. )
> >>>
> >>>
> >>>
> >>>>What gui library? FLTK? GTK? TK? QT? I think they are
> >>>>all cross platform by now.  
> >>>
> >>>
> >>>No idea. I'd like to use whatever makes the most sense for fairly easy 
> >>>to develop cross platform open source and licensed unhindered 
> >>>development. Anyone have suggestions in that regard? Part of my intent 
> >>>is to make an example of a csound GUI wherein the GUI is in the host app 
> >>>and not within csound, but I'm a total newbie in the GUI department. Any 
> >>>opinions in that department would be appreciated.
> >>>
> >>>
> >>>
> >>>>Keep me informed. 
> >>>
> >>>Will do!
> >>>
> >>>Iain
> >>
> >>
> > 
> > 
> > ------------------------------------------------------------------------
> > 
> > Spam detection software, running on the system "saltspring.csc.uvic.ca", has
> > identified this incoming email as possible spam.  The original message
> > has been attached to this so you can view it (if it isn't spam) or block
> > similar future email.  If you have any questions, see
> > adm-Y8W2RYYVBFosA/[email protected] for details.
> > 
> > Content preview:  I have made 2 gui systems for CSound. 1 is EventGUI a
> >   java based Gui Framework for controlling CSound instruments during
> >   performance. The 2nd is FastGUI an SDL::Perl based Gui Framework for
> >   controlling CSound instruments during a performance. FastGUI is
> >   effectively a widget set designed for realtime performance purposes.
> >   [...] 
> > 
> > Content analysis details:   (5.2 points, 5.0 required)
> > 
> >  pts rule name              description
> > ---- ---------------------- --------------------------------------------------
> >  1.2 CS_VGA_3               BODY: Plugs Viagra.
> >  1.0 CS_VGA_10              BODY: Slight possability this is a Viagra add.
> >  3.0 BAYES_99               BODY: Bayesian spam probability is 99 to 100%
> >                             [score: 1.0000]
> > 
> > 
> 
> _______________________________________________
> csoundtekno mailing list
> [email protected]
> 
> Subscribe, unsubscribe, change mailing list options:
> http://plot.bek.no/mailman/listinfo/csoundtekno
> 

-- 
abez ------------------------------------------
http://www.abez.ca/ Abram Hindle ([email protected])
------------------------------------------ abez
SpamAssassinReport.txt (text/plain, 1.2 KB)
Spam detection software, running on the system "saltspring.csc.uvic.ca", has
identified this incoming email as possible spam.  The original message
has been attached to this so you can view it (if it isn't spam) or block
similar future email.  If you have any questions, see
adm-Y8W2RYYVBFosA/[email protected] for details.

Content preview:  It simply sends text through pipes. I have a modified
  CSound which accepts UDP messages which works very well for decoupling
  the GUI from Csound. abram On Sat, 17 Jul 2004, iain duncan wrote:
  [...] 

Content analysis details:   (5.0 points, 5.0 required)

 pts rule name              description
---- ---------------------- --------------------------------------------------
-1.0 CS_GRAD_2              BODY: Mentions an academic degree.
 0.8 CS_REMOVE_1            BODY: Almost 'please remove'.
-2.0 CS_UVIC_1              BODY: A UVic email.
 2.0 CS_VGA_1               BODY: Plugs Viagra.
 1.2 CS_VGA_3               BODY: Plugs Viagra.
 1.0 CS_VGA_10              BODY: Slight possability this is a Viagra add.
 3.0 BAYES_99               BODY: Bayesian spam probability is 99 to 100%
                            [score: 1.0000]