Well, if you can get the timetag aspect of OSC working, then it would
be good. You just need to set the delay on the OSC timetags to be
greater than the jitter, then it will be reliable (as reliable as your
computer's clock). That is, of course, depending on implementation.
Many if not most OSC implementations do not do timetags, AFAIK.

.hc

On Wednesday, Dec 3, 2003, at 13:43 Europe/Brussels, joreg wrote:

halo.

in a recent setup i had to sync a pc that generated sounds to another that did the visuals. all tests with udp or tcp connections were unsatisfying. the beat was not received constantly on the other machine. now i do it with midi and am happy. i didn't measure anything but a jitter is no longer obvious.

osc will not be better than netsend via udp since it still uses udp.

grkks. joreg.

JS> does anyone have any good experience getting *very* tight timing
sync JS> between two computers running pd? for my first attempt i just used JS> [netsend]/[netreceive] to send a message (the number of the current JS> measure) and got really nasty jitter (10's of ms). last night i
banged JS> out a little net latency test patch and the results were so bad i JS> decided i was tired and it must be a problem with my code ;)

JS> so... how have you achieved tight timing sync? should i give up on JS> network sync and just use a midi cable? how about OSC?

--cut here------------------- current: http://vvvv.meso.net allstar: http://joreg.ath.cx

---

PD-list mailing list PD-list@iem.at http://iem.at/cgi-bin/mailman/listinfo/pd-list

Using ReBirth is like trying to play an 808 with a long stick. -David Zicarelli

At 9:47 AM -0500 12/16/03, B. Bogart wrote:

I need to do some syncing, but not sample accurage, 1/60th of a second would be sufficient I think.

Do I need to worry about jitter? What delay size is commonly needed for sample-accurate stuff?

Thanks b.

SuperCollider uses timetags to schedule events if I'm not mistaken. The thing about timetags is that you have to schedule everything in the future - you cannot say 'do this NOW!'

I would look into setting up an object that would keep track of a timeline and fire off received events at the specified time with an acceptable amount of granularity and jitter. This could be placed at either the send or receive end of the chain and do something like this:

myType *eventQueue; //holds all the event data int event; //which event in the queue

if (timenow+ jitteroffset + granularity <= timenow + interval) {

//there is enough time to this event and it's within the 

specified window //send out the float or list or symbol in eventQueue[nexttime] to an outlet

event++;  //increment by the callback interval of the timer

//possibly call s_clockdelay

}else
{
//whoops not enough time for out event
//figure out what to do with a missed opportunity ;)
}

This would most likely achieve Ben's 1/60 of a second accuracy, but sample accurate timing would probably require a DSP loop.

cgc

At 10:19 AM +0100 12/16/03, Hans-Christoph Steiner wrote:

Well, if you can get the timetag aspect of OSC working, then it would be good. You just need to set the delay on the OSC timetags to be greater than the jitter, then it will be reliable (as reliable as your computer's clock). That is, of course, depending on implementation.
Many if not most OSC implementations do not do timetags, AFAIK.

.hc