Joining this conversation a little late, but what the heck... On Feb 22, 2012, at 9:18 AM, Michael Gogins wrote:
> I got my start in computer music in 1986 or 1987 at the woof group at > Columbia University using cmix on a Sun workstation. Michael was a stalwart back in those wild Ancient Days! > cmix has never > had a runtime synthesis language; even now instrument code has to be > written in C++. One possible misconception -- by "runtime synthesis language" I'm sure Michael means a design language for instantiating synthesis/DSP algorithms *in real time* as the language/synth-engine is running. I tend to think of languages like ChucK or Supercollider more in that sense than Csound, and even SC differentiates between the language and then sending the synth-code to the server. RTcmix (http;//rtcmix.org) works quite well in real time, in fact it has now for almost two decades. The trade-off in writing C/C++ code is that it is one of the most efficient languages currently in use. We've also taken a route which allows it to be 'imbedded' in other environments. rtcmix~ was the first of the 'language objects' I did for max/msp. iRTcmix (RTcmix in iOS) even passes muster at the clamped App Store, check out iLooch for fun: http://music.columbia.edu/~brad/ilooch/ (almost 2 years old now). For me the deeper issue is how these various languages/environments shape creative thinking. I tend to like the way I think about music, especially algorthmic composityon, using the RTcmix parse language than I do in, say SC. Each system has things 'it likes to do', and i think it important to be aware of these. brad http://music.columbia.edu/~brad -- dupswapdrop -- the music-dsp mailing list and website: subscription info, FAQ, source code archive, list archive, book reviews, dsp links http://music.columbia.edu/cmc/music-dsp http://music.columbia.edu/mailman/listinfo/music-dsp
