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

[Daniel Trueman]

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