Hi Michael, I've taken a look at ChucK and SuperCollider and many other programs and always return to Csound. I like that I can use multiple methods to target the Csound note format for score generation. I find the language of Csound ORC to be quick to code in and has a rich wealth of tools and examples. The speed to code new instruments and sounds far outweighs the occasional inelegance of the language for me. If I was to use other sound programs, I think I'd end up reinventing the same music model of Csound and would use those programs in the same way I use Csound, but I'd be without all of the history, depth of opcodes, and community that's here. So for me, looking at these other tools, while they have things which are nice features to have, they miss many other things which are inherent to Csound which I enjoy, and the features they have do not affect my music making capacity in such a way to offset what I'd lose in switching. Regarding the multiprocessor Csound, it is Extended Csound (I couldn't remember the name for it!) that I was referring to and not any new project. steven On 3/24/06, Michael Gogins wrote: > 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 > > > > -- > Send bugs reports to this list. > To unsubscribe, send email to csound-unsubscribe@lists.bath.ac.uk >