[chuck-users] syncing computers with OSC

Wed Jan 28 11:03:04 EST 2009

If you experience delays with OSC, I've heard about some kind of Nagle
setting that can be tweaked in the OS. That shouldn't principally affect
UDP, but I have a diffuse feeling that I've heard somewhere that it might
anyway.

Re: system clocks - these can drift quite a bit. I've experienced computers
that drifted 10 minutes in half a day if I didn't synch them to a server. I
don't know how ChucK reacts to the system clock being set (e.g. from a NTP
server) while the VM is running. Of course most computers will have good
enough clocks I guess.

/Stefan

On Wed, Jan 28, 2009 at 7:58 AM, <james.hurlbut at utoronto.ca> wrote:

> This sounds like a very interesting solution to get very precise
> synchronization if it would work. Unfortunately, I don't see that Chuck has
> any Date/Time functions. I see Scott Wheeler made a library but editing and
> recompiling the source is a little more involved than I hoped.
>
>
> Quoting Robert Poor <rdpoor at gmail.com>:
>
>  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<http://music.princeton.edu/%7Edan/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
>>>
>>
>> _______________________________________________
>> 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
>

-- 
Release me, insect, or I will destroy the Cosmos!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cs.princeton.edu/pipermail/chuck-users/attachments/20090128/f830cac8/attachment.htm>