On Feb 24, 2012, at 3:25 AM, Ross Bencina wrote: > CSound does not have a runtime synthesis language either. It's a compiler > with a VM. There is no way to re-write the code while it's running.
Exactly. I've been messing with the idea of rolling up our RTcmix dynamic-loader into a text-edtitor with compilation capabilities to allow direct coding in C/C++ that can then be immediately instantiated in a running audio process, but it still has that separation. And at some point it just gets kind of silly. > SC3 is very limited in this regard too (you can restructure the synth graph > but there's no way to edit a synthdef except by replacing it, and there's no > language code running sample synchronously in the server). So you have a kind > of runtime compilation model. > > I didn't get much of a chance to play with SC1 but my understanding is that > you could actually process samples in the synthesis loop (like you can with > cmix). To me this is real runtime synthesis. You get this in C/C++ too -- > your program can make signal dependent runtime decisions about what synthesis > code to execute. > > Anything else is just plugging unit generators together, which is limiting in > many situations (one reason I abandoned these kind of environments and > started writing my algorithms in C++). The only language I'm aware of that allows the design of direct sample-massaging code in the language itself is chuck. But it also has a healthy set of unit-generators, because when you reduce the script-execution loop to a sample it becomes *extremely* inefficient. Chuck ugens are coded in C/C++. 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
