On 11/11/15 14:45, i go bananas wrote:
But i don't think you properly see what my workaround does.
See, the problem is not with latency, per say...because the Link framework has that covered...so we can have quite a bit of latency,
Yes you're right, if they are doing latency compensation then the most important thing is consistent latency. In that case, doing a [pipe] or [delay] hack should hopefully work.
So, what you get, is this system where messages are only processed in the audio thread every time that multi-block boundary is reached....just as messages in pd itself are just added to the audio thread on block block boundaries.
Yep, I think that's right.
SyncJams is implemented in Pd itself so I don't have this issue - everything happens in the correct logical time without [pipe] hacks etc.
and as far as i know, all devices just sync to the slowest one.
The algorithm that SyncJams uses is quite simple:
- All nodes keep their own internal metronome (integer counter).
- All nodes broadcast their metronome counter value every tick.
- If a node ever receives a metronome value that is *higher* and
*earlier* that its own metronome, it immediately jumps to the incoming metronome's phase + value. Higher & earlier is treated as always "more correct".
The effect of this is that all nodes sync to the fastest network ping time that is experienced during a session. So if the network has a general latency of 10ms but some packets sneak through in 3ms then the sync difference will be 3ms. The overall effect is that sync gets tighter over time monte-carlo-asymptotically towards the optimal possible latency given the hardware. It also means there is no master/slave setup and that the metronome that every node is syncing to is the virtual "consensus" metronome that emerges from the network rather than one specific node having the best or most correct clock.
Each node assumes it is not the best node, and thereby the group benefits during consensus.
Cheers,
Chris.