[chuck-users] syncing computers with OSC

Robert Poor rdpoor at gmail.com
Tue Jan 27 21:00:07 EST 2009


James:

I'm a little confused.  You asked if you could get sample accurate  
ChucK sync between two laptops.  Yet it appears that everyone is  
trying to tell you how you can (or can't) pass synchronized  
performance data among laptops, how bandwidth and latency will get in  
the way, etc.  The two problems are very different.

I'm assuming that you really just want to synch multiple ChucK VMs,  
not pass massive amounts of data.

I am not a ChucK expert, but IF it is possible to slave a ChucK VM to  
the system clock on its local machine, then each ChucK VM will then be  
as closely sync'd as its respective host's system clock.    For sake  
of argument, let's assume this is true.  [Could a ChucK expert weigh  
in here and say if this is possible or not?]

So the problem reduces to sync'ing system clocks on multiple laptops.   
In your case, you only need to synch TWO laptops, and I infer from  
your comment that there's a WiFi link between your laptops.  The most  
prevalent synchronization protocol, NTP, ships with every machine and  
will get you within 1mS synchronization on a local area network.

But the question on my mind: do you REALLY need sample accurate  
synch?  Sound travels 34 centimeters in 1 millisecond -- you incur  
that kind of timing error just by moving your speaker by a foot.  The  
only case where I could imagine that sample accurate synch is really  
important is when you are trying to divvy up a four channel sound file  
among two machines in which case the phase relationship among the  
channels is important.

But in any other situation, I'd invest the time in getting ChucK to  
slave to the system clock and simply let NTP synch multiple machines  
-- that part is already done.

Let me know what you find.

- Rob

On 27 Jan 2009, at 17:04, Stephen Sinclair wrote:

> I don't know about ChucK's support for OSC bundles, but if you send a
> clock signal with explicitly timestamped OSC bundles it should be
> possible to find a constant delay for each receiving computer and get
> pretty good synchronization.  I haven't tried this myself however.  It
> would definitely be an interesting exercise.
>
> Steve
>
>
> On Tue, Jan 27, 2009 at 7:39 PM, kevin <vacillates at gmail.com> wrote:
>> nobody in plork or slork is synced, which is, in my opinion, one of  
>> its
>> stronger points. the music sounds more attached to the performers  
>> and less
>> attached to a computer, if that makes any sense.
>>
>> intra-computer sample-accurate syncing over a network is difficult  
>> because
>> neither TCP nor UDP are suited to such things. TCP guarantees packet
>> delivery by requiring a call-back (sometimes called a handshake).  
>> if the
>> sender does not receive a call back, it assumes that the packet was  
>> dropped
>> and then resends info. this works for things like websites, where the
>> request is not time-sensitive.
>>
>> UDP on the other hand, does NOT guarantee packet delivery, and thus  
>> expects
>> no call back. when packets get dropped over UDP, the sender is not  
>> notified,
>> so the sender will not resend. this is better in situations like  
>> VoIP, where
>> a single dropped packet will not ruin the audio stream (sure,  
>> there'll be a
>> noticeable glitch). the idea is that if you're talking to someone,  
>> you'd
>> rather hear a glitch than hear that packet arrive 5 seconds later.
>>
>> without modification, neither are sufficient for real-time  
>> synchronization.
>>
>> and even if they are, wifi bandwidth will definitely get in your  
>> way. i
>> haven't looked at any numbers, but i'd intuitively guess that wifi  
>> drops
>> more packets than wired.
>>
>>
>>
>> On Tue, Jan 27, 2009 at 4:15 PM, <james.hurlbut at utoronto.ca> wrote:
>>>
>>> I see. so none of the Plork pieces are dependant on precise
>>> synchronization? I guess because I am coming from a dance music  
>>> background
>>> its more critical for me that the music is running off a master  
>>> clock. I was
>>> thinking that Chucks strongly timed quirkiness would enable me to  
>>> send
>>> sample accurate osc messages albeit at a very high speed cost. I  
>>> suppose I
>>> can try midi but was hoping for a wifi solution.
>>>
>>> Quoting dan trueman <dtrueman at princeton.edu>:
>>>
>>>> i don't think there is any way to get sample-accurate sync via
>>>> conventional networking...
>>>>
>>>> dt
>>>>
>>>> On Jan 27, 2009, at 6:51 PM, james.hurlbut at utoronto.ca wrote:
>>>>
>>>>> Hi, chuck newbie here. I am wondering what the best way to get  
>>>>> sample
>>>>> accurate sync between two laptops. I have tried using
>>>>> http://music.princeton.edu/~dan/plork/autosocket_chuck.zip but  
>>>>> the two
>>>>> computers receive the 16th beats at slightly off times. I also  
>>>>> have
>>>>> tried sending an osc message every sample or 100 samples but that
>>>>> completely bogs down the machine. Is the solution to have one  
>>>>> machine do
>>>>> all the audio and another just send program changes? Thanks,
>>>>>
>>>>> James
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> chuck-users mailing list
>>>>> chuck-users at lists.cs.princeton.edu
>>>>> https://lists.cs.princeton.edu/mailman/listinfo/chuck-users
>>>>
>>>> _______________________________________________
>>>> chuck-users mailing list
>>>> chuck-users at lists.cs.princeton.edu
>>>> https://lists.cs.princeton.edu/mailman/listinfo/chuck-users
>>>
>>>
>>>
>>> _______________________________________________
>>> chuck-users mailing list
>>> chuck-users at lists.cs.princeton.edu
>>> https://lists.cs.princeton.edu/mailman/listinfo/chuck-users
>>
>>
>> _______________________________________________
>> chuck-users mailing list
>> chuck-users at lists.cs.princeton.edu
>> https://lists.cs.princeton.edu/mailman/listinfo/chuck-users
>>
>>
> _______________________________________________
> chuck-users mailing list
> chuck-users at lists.cs.princeton.edu
> https://lists.cs.princeton.edu/mailman/listinfo/chuck-users



More information about the chuck-users mailing list