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, 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 :

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@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.ziphttp://music.princeton.edu/%7Edan/plork/autosocket_chuck.zipbut 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@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users

_______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users

_______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users

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 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, 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 :

...

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@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@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users

_______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users

_______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users

_______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users

_______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users

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 :

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 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, 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 :

...

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@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@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users

_______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users

_______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users

_______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users

_______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users

_______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users

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, 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 :

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@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@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users

_______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users

_______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users

_______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users

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 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, 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 :

...

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@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@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users

_______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users

_______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users

_______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users

_______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users

-- http://michaelclemow.com http://semiotech.org

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 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, 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 :

...

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@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@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users

_______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users

_______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users

_______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users

_______________________________________________ chuck-users mailing list chuck-users@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@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users

_______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users

Wow. This reminds me of a show I saw. In a basement of a club, two extremely tall guys in matching striped shirts sitting at a desk with two mac laptops. They each had really shiny shaved bald heads, and they would bob in unison, even when they changed pace. I can't remember what kind of music they were playing, only their heads bobbing slowly in perfect coherence. Rogan On Wed, Jan 28, 2009 at 8:20 PM, dan trueman wrote:

hilarious, sometimes; i was trying something last week with TCP, checking timing, and, sure enough, messages would always be received, usually in a timely fashion, but others would go get a cup of coffee before arriving. not very helpful in a musical context! paul lansky's piece for PLOrk had the performers manual sync their clocks; they'd conduct a downbeat and hit their spacebars together. totally radical. dan

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

TCP is pretty flaky with reception delays, though.

_______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users

On Wed, Jan 28, 2009 at 9:56 PM, Kassen wrote: ...

Most modern mainstream OS's aren't even realtime so unless you go Linux with a RT kernal no guarantees can be made at all about when messages will arrive and I'm not even sure to what degree a RT kernal will affect TCP-ip message processing.

We were using RT Linux. Still didn't work. ;-)

In short; I'd abandon this as a goal and shoot for a situation where I didn't notice any latency anymore, then simply go with that.

Better than that, my partner has decided that the failures inherent in the network make for great music, if exploited! -Mike

On Wed, Jan 28, 2009 at 9:56 PM, Kassen wrote:

Some notes;

A remark was made about the importance of timing in dance music. I don't think sample accuracy is mandatory there, at least not for sequencing. Even a well implemented MIDI clock (Atari,old MPC's) will service there beyond what most people need and MIDI is slooooow. Bad MIDI clocks may be a issue and require work-arounds. If you can get it down to the MS range for jitter and latency you are set, I'dsay.

I think any vinyl-loving DJ will agree with you on that. You can get away with tweaking and nudging the speed of a record while it's playing in order to keep the two beats synchronized, without it being audible. Interestingly, if you do this with two copies of the same record, you can hear an obvious manual flanging (comb filtering) effect. On a similar note, for a while circa 2001 I used to 'DJ' music in Impulse Tracker using two computers. (Impulse was a music sequencing program for DOS) They would drift apart, but I didn't use MIDI synchronization, just ear tracking and a keyboard shortcut for adjusting the BPM of the track, to keep them synched. Good times :) Steve

So my thoughts: a) for sync just use UDP, if you miss a sync message, who cares. Sync should really only be used to nudge the tempo's back together. Just ignore any sync messages that come out of order, you'll save bandwidth once you start syncing a bunch of computers. b) to get a handle on the latency (which is probably what you're hearing if you're syncing over a LAN), you can periodically do a round- trip adjustment. You send a UDP ping out, wait for a return and measure the round-trip latency. Divide that by two and you've got a good pre-delay for the master. Then you make sure to delay the master by the pre-delay you've found. Super simple and effective. so you go like this: 1) determine the latency via 1/2 round trip (call that latency L milliseconds). 2) start looping, 24 times a quarter note L milliseconds before the next pulse do the following: send out a sync message that says it is the next 24th of a quarter note now, use a monotonically increasing sequence number. 3) on the slaves, when you get a sync from the network make sure it's higher than your current sequence number, then hard sync to the sequence number right now. 4) everybody determines what the time is by taking the number of samples from the last sequence number plus the number of samples per sequence number times the current sequence number. If you miss a sequence number, this should still work out. This exercise sounds really interesting, so I might just try it and post some code. cheers! On Jan 29, 2009, at 8:56 AM, james.hurlbut@utoronto.ca wrote:

Hi Guys, thanks for all the input to my question. As you can see in my original post, my issue was with the sample OSC sync code I downloaded from the Plork site which was generating 16th note sync messages that were way off to any pair of ears. So yes, my question was concerning creating decent musical sync messages over OSC.

Sure, my players can gaze each other deep into the eyes or setup some sort of janky nudging system but for my purposes I need things to be musically synced bpm wise as the players will have little or no musical talent, and well, lined up beats just sound good to my MTV ears.

Sorry if I set off all y'alls ubernerdiness with the incorrect "sample accurate" description. Kassen, you being an electro rock star, maybe you have some insights or code to share to get an aspiring chuck dj superstar on the way to synced techno bliss? I would much prefer to be spending my limited chuck time making music than figuring out the idiosyncracies of UDP. Thanks all!

james

_______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users

_Mark pauley@unsaturated.net