[chuck-users] syncing computers with OSC

Brad Garton garton at columbia.edu
Wed Jan 28 21:11:16 EST 2009


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
>



More information about the chuck-users mailing list