[chuck-users] syncing computers with OSC

[Brad Garton]

One more thing -- do be wary of UDP, it *does* drop packets sometimes.
TCP is pretty flaky with reception delays, though.  I even tried writing
some custom socket code and found some really weird timing issues
that I think were related to internal Apple network device driver  
buffering.

brad
http://music.columbia.edu/~brad


On Jan 28, 2009, at 9:11 PM, Brad Garton wrote:

> Yeah, I don't think IP was set up for "sample accuracy".  Maybe on an
> I2 network.  I guess one possibility would be to transmit an audio
> signal and design some kind of phase-locking system that would
> keep sync, but delays might(!) creep into such a system without  
> detection.
> I recall Chris Chafe telling me about a really snazzy thing they had  
> done
> at Stanford where they used the delay inherent in IP transmissions as
> a delay-line for a phys model like the Karplus-Strong algorithm;  
> they would
> periodically 'pluck' the delay line and the shift in pitch would  
> signal
> how much latency was being introduced (I think this was intended for
> remote operations where knowing the delay was important).
>
> In my pLOrk piece, I sent a 'sync' pulse about every 0.5 seconds from
> one machine, and all others would reset their clocks to correspond  
> with
> this.  It worked fairly well, although 'sample-accuracy' is in the  
> ear of the
> beholder, I suppose.
>
> Another technique is to have the performers actually look at each  
> other...
>
> brad
> http://music.columbia.edu/~brad
>
>
> On Jan 28, 2009, at 3:59 PM, mike clemow wrote:
>
>> We looked into doing this while running Chucks on a cluster here at
>> NYU and realized that for things like sample-accuracy (or
>> sub-sample-accuracy, god forbid) even NASA has significant problems.
>> I think that some sort of hardware system (cesium clock or something)
>> is necessary for that.  Obviously, that's outside of everyone's
>> budget.  ;-)
>>
>> But syncing tightly enough for musical performance should be  
>> totally possible.
>>
>> -Mike
>>
>> On Tue, Jan 27, 2009 at 10:22 PM, dan trueman  
>> <dtrueman at princeton.edu> wrote:
>>> well, we actually do a lot of synchronization over the network,  
>>> and it works
>>> amazingly well (with UDP). it's nowhere near sample accurate, but  
>>> it's
>>> musically powerfully accurate, and it's important to keep in mind  
>>> that
>>> "accuracy" in something like plork is not easy to define, since  
>>> all the
>>> sound sources (multichannel hemispheres) are spatially separate  
>>> and there is
>>> a lot going on with phase -- the speed of sound becomes a major  
>>> factor!
>>> if you are mixing multiple computers with a mixer, then i can well  
>>> imagine
>>> that network sync will be insufficient, but when the room is doing  
>>> the
>>> mixing, it is almost overly accurate; it feels un-natural how well  
>>> a large
>>> ensemble can sync this way (and it is!).
>>> dt
>>>
>>> On Jan 27, 2009, at 7:39 PM, kevin 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
>>>
>>>
>>
>>
>>
>> -- 
>> http://michaelclemow.com
>> http://semiotech.org
>> _______________________________________________
>> 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
>