i've come to view this as a feature, not a bug... ;--}
I certainly feel that PLOrk's "conductor" approach is a very interesting idea that does expose a lot of the things we often assume to be given for what they are.
Still; it doesn't need to be a either/or thing.
oh, i know this, and we do both. until this year we had excellent success synchronizing the ensemble over the network; i've written about this elsewhere. 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. 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." dt
In case of emergency you can always add a random offset to timestamps so the amount of jitter can be set to suit the mood. :¬p
Here's one I prepared earlier;
//returns a random duration in a given range //works like Std.rand2(int, int) and Std.rand2f(float, float) fun dur rand2dur( dur min, dur max) { return min + Std.rand2f(0,1)::(max - min); }
Kas. _______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users