[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