until this year we had excellent success synchronizing the ensemble over the network; i've written about this elsewhere.
You wrote about dealing with a wireless network for musical sync? Do you have a link for that?
it's not a technical paper, but a paper about the musical effects of the syncing, which at the time was quite amazing. http://music.princeton.edu/~dan/plork/papers/WhyALaptopOrchestra.pdf this was all done with OSC/UDP and a Airport, with 15 laptopists.
I think SLUB simply switched to using cables but then they are just 3 guys. It's probably more convenient to use cables when you have three friends than when you have a group of 30 students.
exactly. i've used wires with quartets. i won't with plork.
this year we've been exploring other ways of doing it that i find quite interesting, but we've also had some more difficulties with the network sync, in part (i think) because we've gotten larger; synchronizing 30 laptops seems to be harder than 15.
This makes perfect sense. I also wouldn't be surprised if Apple occasionally tweaked their implementation and likely they are more concerned with things like throughput for things like streamed video than with syncing up 30 performers. There are quite a few variables.
yep! mark ran some tests and found that at least wiring the server to the airport would noticeably improve performance, as well as turning on Network Interference Robustness, or whatever it's called. at the moment the network seems to be working well, but the difficulties encouraged us to try other strategies, which has been quite interesting. for instance, to sync with Matmos, running a specific BPM, we've had the players simply use their ears (!) to sync. this has worked quite well, and with a distributed audio system like PLOrk, it may well be that this kind of sync is *better* than network sync. dt
but even clock/timestamp syncing is not quite the same as the syncing we've done in the past, where a single server machine can say to all the other machines, do THIS, NOW. we've been able to do this in the past with 15 machines, and hopefully we'll be able to figure out a way to do it well (wirelessly) with >15. so, while i'm looking forward to having a good timestamp system of some sort, it will be one of several ways we go about "syncing."
I see. That indeed is different. NetClock is more about sharing a clock that sends pulses (or events in ChucK's case). From the user's perspective I think it would work like the clock I've been using when livecoding lately (I'll post it below to illustrate). That need not be a issue; maybe we can work at interoperability in the interest of cross-platform jamming. I'd also be happy to implement NetClock for ChucK myself. If I'd have access to timestamps I think I could do it entirely in ChucK itself.
I hope nobody minds that I'm a bit fanatical about this but I've been very interested in synced livecoding jams since I realised the guy who has a radio show before mine uses SC and the one after me uses PD. Synced jam session would be nice for us; I'm purely being selfish here :¬). Then again it works on SC, Perl and Haskel now, I think, with Fluxus, Impromptu and PD in the works, somebody mentioned Processing as well. To me that's exciting; I don't like MIDI that much but I do like the convenience of MIDI clock and how it allows for jam sessions without having to first agree on some protocol. It's also interesting to me how all of these systems deal with time and timing in quite different ways so they will likely all abstract this shared clock in a different way towards the user; to me that's a beautifull thing.
Yours, Kas. _______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users