On Thu, 2009-03-05 at 11:33 +0100, Kassen wrote:
> I really like how this looks. With clients all having their own clock
> instead of depending on periodic pulses (as in a analogue sequencer)
> it'll be easier to abstract it in ways that make sense within the
> individual systems. PD and CK deal with clocks and timing in quite
> different ways and so a "net clock" should look quite different to
> both. With a internal clock per client it would -for example- be
> easier for ChucK to poll the clock for the current duration of a
> quarter note as that info should explicitly be there, as opposed to
> implicitly as in -say- MIDI.
Yes, periodic pulses work in a nice messy kind of way, but you always
get jitter and being able to manipulate time in a cleverer way makes
more things possible.
I guess periodic pulses _are_ used by ntpd and ptpd to keep the system
clocks in sync, but in a bidirectional, clever way that is not worth
re-implementing in OSC.
Netclock is implemented in a very supercollider manner, but I think
you're right, it's general enough to implement different APIs to fit the
various language flavours of time...
> I assume this format could be extended to feature things like notes
> and bars, maybe even "sections"? And that we could then change
> time-signature based on one of the clients defining a new one?
Yep, and actually Jamie already implemented bars.
> That would be quite nice and would likely lead to more interesting
> algorithms; I know I'd be programming rhythms in different ways then
> I'd normally do if I knew ahead of time you or Artem could be changing
> the time-signature at any moment.
Heh
alex
Received on Thu Mar 05 2009 - 10:51:10 GMT