On Wed, Jan 28, 2009 at 7:58 AM,
<james.hurlbut@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@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@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@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@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@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
_______________________________________________
chuck-users mailing list
chuck-users@lists.cs.princeton.edu
https://lists.cs.princeton.edu/mailman/listinfo/chuck-users