Hmmm
Whenever i do this i've just used UDP messages and sent either beat counters
or just pulses..
I pretty sure that most other protocols use UDP/TCP (OSC for example)
Its quite easy in PD to write your own UDP parsing patches etc...but often
just picking up a groove counter works..
(and it seems to be pretty reliable too)
I sometimes run workshops and use a master clock that can be picked up by
all the clients via a local network UDP port..
But if you are talking about timing at buffer/chunk level then I'm not sure
it can be acheived very easily (especially if people are using different
samplerates etc)
(I guess you might be able to sync or something, but obvioulsy any network
speed will be slower than samplerate..)
----- Original Message -----
From: "alex" <alex_at_state51.co.uk>
To: <livecode_at_slab.org>
Sent: Monday, August 30, 2004 6:14 PM
Subject: Re: [livecode] timing is everything
> On Mon, 2004-08-30 at 16:56, Julian Rohrhuber wrote:
> > osc has quite a good system for timing I think.
> > It uses the NTP time server, to create time stamps according to the
> > osc time format (64 bit, first 32bit is seconds since 1970, second 32
> > is divisions of a second).
> > You then simply schedule the packets ahead in time, so the maximum
> > lag time is accounted for. This way you get very exact timing.
>
> Yep but OSC doesn't really have a system for timing beyond being able to
> specify that timestamp. I mean, OSC doesn't directly interact with NTP
> beyond borrowing its timestamp format, does it?
>
> http://www.cnmat.berkeley.edu/OpenSoundControl/OSC-spec.html
>
> NTP is great for synchronising clocks before and during a live jam, but
> the various systems also need to start at the same time and go at the
> same speed. If one joins in while others are running then it needs to
> be able to work out when to start, and when the speed is to change all
> the systems need to know about it.
>
> It would be great to work out a TOPLAP standard for time synch, a simple
> one that is easy to implement. Does anyone feel like working something
> out together? I don't mind taking my system apart and describing it in
> detail if it would help, but bear in mind that while it works in
> practice without drifting, it is fairly naive.
>
> The time server is here:
> http://cpan.org/authors/id/Y/YA/YAXU/perl-music-article/examples/tm-0.1.pl
>
> and the client side stuff is here, in the spread_event_loop() routine:
>
http://cpan.org/authors/id/Y/YA/YAXU/perl-music-article/examples/feedback-0.1.pl
>
> I'm using the 'spread' protocol and libraries to send timing information
> around out of programmer's laziness, it would be better to use OSC for
> this. When it comes to sending messages to SuperCollider, I'm using
> timestamped OSC bundles, with a little bit of buffering as Julian
> describes.
>
> Or does an OSC based timing protocol already exist without me knowing
> about it? How does SuperCollider deal with this? Klippav, how do you
> keep SuperCollider and Max in synch?
>
> alex
>
>
>
>
Received on Mon Aug 30 2004 - 17:41:32 BST