[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [sc-dev] demand rate
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)
kr or ar rate (which feels like you don't control it, it gets wet
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