|
Hi James,
Is the basic approach to have one process play a beat ahead of the others, in the same manner a conductor provides cues? How do you implement this - with multiple server-like objects that define the different latencies? Seems like you could do this with ~lag, Or listening patterns could do a zero duration rest before each note, to make sure they are the last to perform at any time point ( although round off error may be a problem.)
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.)
RJK
On Dec 18, 2007, at 10:48 PM, James Harkins wrote: On Dec 18, 2007, at 9:57 PM, Julian Rohrhuber wrote: In some cases it may be practical to do otherwise, but I think latency should not be used for scheduling, but only for taking into account the network latency headspace. So s.latency is a property of the connection and not of the scheduling processes.
While we're on the subject then... say you have a bass pattern and a chord pattern. A new chord *might* trigger at the same time as a bass note, but it might not be synchronized. If they are not synchronized, the chord should use the previous bass note to determine the root to conform to. If they do happen at the same time, the new bass note *must* calculate first. Keeping in mind that you have no control over the order in which threads wake up if scheduled for the same logical time, how do you do this?
My solution... erm, hack?... was stated earlier :) -- I tried once upon a time to create a structure where one process would be the driver but its children could maintain independent timing. It was really convoluted and breakable so I gave up on it. Maybe I'll refactor it someday. For now, using different latency values in beats is actually easier to understand and more reliable.
That's what I like about SC. It doesn't force you to do things only one way. In that spirit, I wouldn't say latency *is* a property of the connection. It is a tool. You *can* use it that way but that isn't the only way, or even the "right" way. hjh
: H. James Harkins .::!:.:.......:.::........:..!.::.::...:..:...:.:.:.:..:
"Come said the Muse, Sing me a song no poet has yet chanted, Sing me the universal." -- Whitman
_______________________________________________ Sc-devel mailing list
|