Zephaniah E. Hull
warp at aehallh.com
Fri May 18 21:13:11 EDT 2007
On Fri, May 18, 2007 at 01:46:24PM -0400, Jean Piché wrote:
> One thing needs solving: a clock pulse over the mesh so the beats
> stay tight. As it is, you can start any number of machines on the
> default tempo, and the machines will stay in sync for as long as two
> or three minutes. This is musically useful but re-synching manually
> kills the "élan". So we need this clock. We have figured out how to
> do it in our code and will, in all likelyhood use the presence
> service. Right now however, the mesh remains slightly mysterious as
> to its usability. We can shortcut with a pipe to Csound itself and
> let it handle sync broadcast and reception outside the sugar
> environment but that seems the wrong way to go.
> A central question remains: Will a lightly loaded mesh (say, 10-12
> machines) show enough latency to be musically objectionable? In
> pratice, sync packets have to reach clients within 10ms, with a
> prefferred figure of less than 5ms. By the time the signal makes it
> up and down the software chain, it gives us something in the order of
> 50ms to make the graphics do what they need to do at that moment.
> This is acceptable as a drop-dead timeframe. Outside this window, the
> music is just going to gradually "loose the groove". Can the mesh
> support this rate continuously? If so, we have a mightily rich
> collaborative music setup.
Could we use ntp on each system to keep the whole mesh in sync time
wise, and just pass time stamps?
Assuming that things are synced closedly enough, that should make it
work even with enough load on the network to up the latency.
1024D/E65A7801 Zephaniah E. Hull <warp at aehallh.com>
92ED 94E4 B1E6 3624 226D 5727 4453 008B E65A 7801
CCs of replies from mailing lists are requested.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 189 bytes
Desc: Digital signature
More information about the Devel