[chuck-users] other ways to live-code with time

[mike clemow]

Mark,

This is fascinating work.  I will definitely try this out as soon as I
graduate (one week left).  I've spent the last year working with ChucK
on a cluster and haven't even tried to attempt synchronization because
the nature of the work I was doing required sample-accurate sync.
We've given up doing what we were doing (because it was insane) and
now I'm excited to test out your implementation in my environment
here.  I'd be happy to provide you feedback, especially considering
you're doing thesis work on it (user testing is key ;-).

Good luck!
_Mike

2009/5/6 Mark Cerqueira <mcerquei at princeton.edu>:
> Hello,
> Last week I sent out an email to the list about a synchronization protocol I
> was working on with Perry and Dan for PLOrk. I thought I'd share the current
> product and invite you all to check it out, try it out, and give me feedback
> if you'd like. All relevant materials can be found at:
> http://www.princeton.edu/~mcerquei/networking/
> The protocol that was rather successful in testing is the Time-Tagged OSC
> (TOSC) and the source code for all that code is in the appropriately named
> folder. Apologies for the lack of comments in the source code for the new
> classes I wrote. The sample client and server programs I wrote have some
> comments which pretty much covers the main differences from OSC to TOSC. In
> the final report pdf file, the TOSC section will outline what's going on in
> general so that's worth checking out. You can also check out a demo that
> compares a controlled recording/TOSC test/OSC test in the Demo.tar file (it
> plays in Audacity).
> I'll be continuing to work on this project next year for my senior thesis.
> There are a number of things I already want to fix/work on, but
> recommendations/suggestions are, again, very welcomed!
> 1. Code everything into the ChucK source code. Everything is written in
> ChucK right now so it can be made more efficient by coding directly into the
> source.
> 2. Improve the NTP protocols. My algorithms to synchronize clocks/calculate
> good time-to-open offsets are very, very, very crude and can certainly be
> improved on. Better NTP = better synchronization.
> 3. Netclock - Making TOSC interoperable with Netclock would be useful, as
> Kassen mentioned in an earlier email.
> Thanks!
> Best,
> Mark
> On Apr 29, 2009, at 1:30 PM, Kassen wrote:
>
> Mark,
>
> That seems quite similar in approach to this;
> http://netclock.slab.org/wiki/index.php/FAQ
>
> I'd like to invite you to have a look at that and perhaps join the
> mailinglist on it. If these two could be made inter-operable it could
> be used to sync ChucK to a range of other open source music and
> graphics systems.
>
> Yours,
> Kas.
>
> 2009/4/29 Mark Cerqueira <mcerquei at princeton.edu>:
>
> I've spent this semester doing some independent work with Perry and Dan on
>
> how to get good network synchronization for PLOrk so that we don't need a
>
> conductor and can focus on doing other things. I implemented a Time-Tagged
>
> OSC protocol similar to the stuff Adrian Freed does. Essentially the
>
> protocol first synchronizes everyone's clock via a protocol that is based on
>
> the Network Time Protocol (NTP). On the PLOrk network, one machine runs as a
>
> NTP Server and all others run as NTP Clients - NTP Clients calculate the
>
> offset of their VM time to the server VM time, as well as keeping track of
>
> the round-trip time of packets sent to synchronize to account for that in
>
> the offset.
>
> Once the clocks are synchronized, packets sent over the network include the
>
> current time (which should be synchronized pretty closely if the above
>
> protocol works) and a time-to-execute offset. When someone receives the
>
> packet they add the current time plus the time-to-execute offset and
>
> schedule the packet to be opened only at that time. The NTP-like
>
> synchronization protocol I described above also keeps track of all RTTs and
>
> broadcasts to everyone what a good time-to-execute field is (i.e. make sure
>
> we give enough time for the packet to travel over the network). If all works
>
> well, everyone should open the packet at the same time.
>
> Not sure how successful this implementation will be...I'm testing it
>
> tomorrow during PLOrk rehearsal! If anyone's interested in seeing the
>
> code/my write-up I can pass around a copy once I *crosses fingers* complete
>
> it and hand it in on Monday.
>
> Best,
>
> Mark
>
> Tom Lieber wrote:
>
> On Wed, Apr 29, 2009 at 12:28 PM, Kassen <signal.automatique at gmail.com>
>
> wrote:
>
> Yeah, a wireless network. And for whatever reason (AirPort updates, OS
>
> X updates, variation in laptop hardware), timing issues got worse from
>
> the previous year. Actually, I don't know how this was solved in the
>
> end, because I think things had improved by the end (or maybe we
>
> stopped relying on the network so much and I didn't notice)...
>
> On Wed, Apr 29, 2009 at 12:27 PM, Daniel Trueman <dtrueman at princeton.edu>
>
> wrote:
>
>
> On Apr 29, 2009, at 11:36 AM, Tom Lieber wrote:
>
>
> A lot
>
> of rehearsal time in PLOrk this past semester was dedicated to
>
> synchronizing the performers because we lacked good network
>
> synchronization.
>
>
> i've come to view this as a feature, not a bug... ;--}
>
>
> I chose my words carefully! There's no way I can view getting
>
> everybody to practice being in sync as a bad thing, but having the
>
> option of good network synchronization means we can make pieces where
>
> players can give their full attention to something else, like making
>
> patterns in beepsh.
>
>
>
> _______________________________________________
>
> 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