[sdiy] Re: [AH] Some thoughts about the future

cheater cheater cheater00 at gmail.com
Thu May 7 22:15:14 CEST 2009

You're looking for ninjam.

On Thu, May 7, 2009 at 9:13 PM, Greg Morgan <greg.morgan at gmail.com> wrote:
> The clock is mainly to define the "conductor" BPM variance and then
> accurately transmit that to the "perfomers".
> A slope of BPM gradually going up over time would be hard to accurately
> predict, so why not just capture it, buffer it, and send it on?
> The furthest extent of this idea is transmit video as well, and have some
> mechanism in place to detect note/bpm changes in advance. That way the
> application could have a musical scroll that is dynamically captured and fed
> in advance of the audio/video stream...
> Greg
> On Thu, May 7, 2009 at 2:51 PM, <james.husted at mac.com> wrote:
>> Do clock errors even matter when the locations of the musicians is at a
>> global distances? There would be delays in hearing what they were doing with
>> those clocks that would be worse than the clock delays them selves. In fact
>> there would be double delay - delay in receiving the clock from a remote
>> source and then the delay in transmission from the receiver back to the
>> sender - not to mention the different delay times to all the different
>> locations in a global setting being all different relative to each other. I
>> am afraid it is impossible globally unless you get quantum mechanics
>> involved.
>> In a local setting - all in one room - all you need for the best sync is to
>> transmit the clocks in the fastest media you can. I imagine that would be
>> optical. SMPTE or house clock sent from a central source in a star array to
>> all receivers would work fine.
>> -J
>> On May 7, 2009, at 11:51 AM, David Moylan wrote:
>> Oh, boy.  That's a bag of worms.  I think the only way to do that is to
>>> send pulses with a timestamp and calculate a difference between pulses on
>>> the other end in software and do some sort of phase locking.  That would of
>>> course have it's own delays but you could probably get the clocks in phase.
>>>  Delay problems would still be apparent when the clock time changes.
>>> However, this says nothing of shared audio and only supports a client
>>> server architecture.
>>> Still could be fun....
>>> Dave
>>> Greg Morgan wrote:
>>>> Well, by global I mean GLOBAL, as in, someone in Europe could clock with
>>>> someone in Japan...
>>>> Greg

More information about the Synth-diy mailing list