New topic as this is getting a bit specialised.
Let me see if I get this straight;
*The NetClock thing consists of; a clock server, a OSC message format, a
client clock that keeps time internally based on incoming messages.
*I could probably hack up a implementation in ChucK without touching C++ by
simply listening for these messages and writing my own clock, then having it
control other ChucK code (aside from time-stamps which we don't -yet-
support).
*The main point of all this is that I wouldn't want to do that on stage,
that we make sure we all interpret the specs in the same way, that it will
be convenient and that C is way faster than ChucK.
*The usage example in SC code shows how to loop through a scale, "ticks"
from the clock tell this loop to advance.
*This is the main purpose of the clock, there is no support for things like
quarter/sixteeth/triplets/etc constructs, the user is expected to build
those based on what's provided if he feels he needs those.
Am I on track so far?
In that case I'd say a ChucK implementation should extend Event (making it
similar to the HID one or MIDI, which would make sense). That way we could
tell it to connect and from there on proceed to "chuck it to now" in order
to make a "shred" (piece of chuck code similar to threads) wait for a clock
tick before doing anything (for example triggering notes based on
conditions). I'd also like to be able to query it for it's current BPM (in
float) and the duration of a beat (in dur). That with some extra stuff seems
to be basically identical to how I read these specs.
What I'd also like is to be able to get a integer that represents what
number this beat would have if we'd start counting at 0 at the start of the
current bar. This could index arrays or I might set some modulo operations
loose on it and so on. Though my clock could make up it's own start of the
bar and get the number of beats to a bar from the server it's not specified
in this protocol that the server will tell me when a bar starts. Unless I'm
getting off track somewhere I'd say that would be a usefull and possibly
quite essential addition.
Does this still make sense? I'm mainly basing this on the docs on the site
but part of the docs consists of SuperCollider code and there might be
aspects to that that I overlooked. So far it appears to me like most of the
internal timekeeping of such a clock should be able to piggyback on ChucK's
internal timekeeping, basically we are just sub-dividing time, reporting on
the results and periodically verifying we are still "in tune".
Yours,
Kas.
Received on Thu Mar 05 2009 - 17:56:52 GMT