On Feb 20, 2006, at 8:17 AM, Julian Rohrhuber wrote:
At 17:02 Uhr +0100 20.02.2006, crucial felix wrote:I quite like the idea of blurring the distinction between : pattern rate (which always feels very "logical" and thinky) andkr or ar rate (which feels like you don't control it, it gets wet and moves).it was precisely because sound and sequence were intermingled that I enjoyed working with SC2. That's where the beautiful blends and vibrating sound objects happened.I, too, miss the simplicity of having one high level language for all processes. The relation between continuous and discrete is much more discrete now..--
I agree with this. Things like Spawn, TSpawn and Sequencer were not good to lose. I never intended the current state to be the end. I always intended on making a fat server that included the language as a plugin that supported Sequencer and TSpawn.
A simpler synthdef spawner ugen would also be possible and has already been discussed in the past on this list. There is an issue of how to name the synthdef to be spawned since currently a ugen can only take numeric arguments, not strings. A ugen can accept a string as a u_cmd argument, but then you have to know the ugen index. An alternative approach would be to assign numbers to synthdefs and have the ugen trigger them by number.
There are a number of ways I think that SC3 is less successful than SC2. One is the separation and loss of TSpawn, Sequencer discussed above. Another is the burden of managing IDs. The OSC implementation on SC2 was better. The ways in which SC3 is more successful than SC2 is that it is much more efficient and glitch free. The separation reduces glitching because language use doesn't affect the synth. Synthdefs are pre- built instead of built on the fly which makes them much faster to instantiate. Buffer coloring improves cache performance dramatically. The group+bus architecture of SC3 is more fluid than SC2 but harder to administrate.