Re: [Sc-devel] Servers with nil latency?

On Dec 19, 2007, at 6:50 AM, ronald kuivila wrote:

Is the basic approach to have one process play a beat ahead of the others, in the same manner a conductor provides cues?

Basically, but it doesn't have to be a whole beat. A tenth or twentieth of a beat is enough.

How do you implement this - with multiple server-like objects that define the different latencies? Seems like you could
do this with ~lag,

To date I have been using custom event prototypes. (Another faulty assumption... if you're using patterns, you must be using the default event prototype.) Latency is a property of the process object, which writes the latency into the event. My prototypes read the latency from the event and divide it by the clock's tempo to get seconds.

That's part of why my suggestion in the other e-mail is important to me. So far I've been able to get by with this because it looks like nobody else is using chucklib. But if it's going to be published in the book, you need to be able to use the default event prototype with chucklib. Which means, either I have to strip useful functionality out of chucklib (what reason do I have to do that?), or the default event should be written in a way that does not get in the way of treating latency differently (where the current code is coercive in this regard).

Testing the patch from the other e-mail, this is all I have to do to have a default event prototype that is compatible with chucklib. Without the patch, I would have to copy the entire event prototype, which is an ugly solution for an object-oriented environment.

Event.default.copy => ProtoEvent(\default);

ProtoEvent(\default).parent.putAll((

getLatencyInSeconds: {

~getLagInSeconds.value + ((~latency ? 0) / (thisThread.clock.tryPerform(\tempo) ? 1.0))

getLagInSeconds: { (~lag ? 0) / (thisThread.clock.tryPerform(\tempo) ? 1.0) }

));

If somebody does Pbind(...).play, it uses the normal, unchanged Event.default - if they stick the Pbind in a chucklib BP object, it uses ProtoEvent(\default). The user doesn't even have to be aware of it.

It sounds like the "one process as driver" idea could be implemented as a sampled function of time using Pstep.
Pstep would model "the changes" rather than what the bass player is actually doing. The players would be
Pchained to the Pstep to enforce an order of evaluation. Would this meet your needs if there were a dynamic Ppar
that would allow you to add new streams within the Pchain structure? (This might be implemented as a
version of Pdef with an 'add' method to attach additional streams.)

I think having separate objects that pass messages among themselves (à la Observer or Mediator) more closely resembles the interaction between human performers, and is probably more suitable for modeling collective musical behaviors. But those designs are going to be pretty individual, probably not something we want to prescribe in the default library.

Really the driver should be silent and just pass information into the other processes :)

hjh

: H. James Harkins

: jamshark70@xxxxxxxxxxxxxxxxx

: http://www.dewdrop-world.net

.::!:.:.......:.::........:..!.::.::...:..:...:.:.:.:..:

"Come said the Muse,

Sing me a song no poet has yet chanted,

Sing me the universal." -- Whitman