Steven, you may be interested in ChucK, an on-the-fly audio processing language that does the midst-of-performance reprogramming you mention.

Are you talking about Extended Csound, or some other newer project of Barry Vercoe's?

Regards,
Mike

-----Original Message-----
>From: Steven Yi 
>Sent: Mar 24, 2006 2:36 AM
>To: csound@lists.bath.ac.uk
>Subject: Re: [Csnd] The future of computer music? (was Re: [Csnd] The future of winsound)
>
>Hi All,
>
>On 3/23/06, Anthony Kozar  wrote:
>> I would say that Csound 5 is more like the future of computer music software
>> INFRASTRUCTURE.  It is a modular, reusable, programmable synthesis engine
>> that can be adapted in hundreds of different ways.
>
>I agree with this, but I think there is more to do to further push
>Csound's possibilities for developers (which I'd like to differentiate
>from Csound as tool for music making and expressing musical ideas,
>which it already does amazingly, in my opinion). More thoughts below.
>
>> For instance, someone could create a GUI effects processor with dozens of
>> preset effects and graphical controls for editing their parameters.  Csound
>> could be the engine underneath of it all, but the user would never see a
>> line of Csound code.  (Cecilia provides this ability with its built-in
>> modules I think).
>
>blue has this capacity in recent releases for user-definable GUI
>effects processors, as well as GUI note generators (ObjectBuilder,
>which can use python or any external program such as Perl, nGen,
>CMask, etc. as the scripting language), and GUI instruments
>(BlueSynthBuilder).  Using all of those together with the built-in
>objects like the PianoRoll and PatternObject, one doesn't need to ever
>see a line of Csound code (well, maybe just a little bit here and
>there).  Even with all of that, you still have the capacity to do all
>the standard Csound things within the environment (write note
>statements, code instruments in csound code, etc.).
>
>Where I see real possibilities for furthering the design of Csound
>will come to some degree with the work that goes into the new parser
>and abstracting out the individual functions that will allow closer
>fine-grained modification of instruments and notes in memory.  Right
>now, Csound parses an orchestra and sets things up in memory which is
>expected to be run as-is: you can perform, rewind, and perform the
>same things again.  As a program designer, one could possibly design
>one's program to not use Csound SCO but to only feed in realtime and
>to sync playing those realtime events from the host with the
>performance time of the engine.  Then one could keep the instruments
>in memory and have dynamic notes (i.e. change a script to regenerate
>notes on the fly while a Csound run is running).  However, one can not
>dynamically modify the flowgraph of opcodes in an instrument, so on
>the fly changes to an instrument is impossible.  One currently has to
>reparse a whole orchestra to do that, and that can be a length
>process, as I recently realized when working with some large
>soundfonts and the fluidsynth opcodes.  As a program designer then, it
>would be great to be able to dynamically replace single instruments
>within an orchestra at least, while being able to dynamically swap out
>opcodes would be great.  These things I think should be able to be
>done if the backend of the parser is done with very fine-grained
>functions.
>
>Just a note though that these thoughts are really only relevant to
>program designers and programs designed to use Csound and do not
>affect Csound usage.  By that I mean that what users see as Csound
>would remain the same, but the changes would allow for programs to be
>made such that Csound stays more active in memory and so could help
>users do their work faster if they can try out changes more quickly.
>
>I'd also like to see a parallel-processing Csound in some form,
>whether it is multi-processor solution with shared memory on a single
>machine, a host/nodes situation that you see in some commercial
>programs like Logic, or a clustered computing grid.  Any of these
>would be nice to eventually have in an open source and freely
>available Csound (I doubt there will be any chance in the future I'll
>have access to Barry Vercoe's multiprocessor Csound anytime soon).
>
>steven
>--
>Send bugs reports to this list.
>To unsubscribe, send email to csound-unsubscribe@lists.bath.ac.uk