Max 4 Live GLOBAL Control? (tempo, sync two machines, etc)

[SimonPHC]

Hi Ableton & Cycling74,

Are there options in Max For Live to influence global functions, like tempo or MIDI Clock in/out?

Will it be possible to easily sync two machines running live through a M4L patch using UDP instead of MIDI? The data rate and accuracy of network packages is much much higher then MIDI Clock, especially on a LAN, so I think this would be great!

if not: feature request!

[Lo-Fi Massahkah]

From what I understand, MfL is Max/Msp/Jitter but NOT standalone. I'm thinking you could most likely use hostsync~ to extract timing and tempo information from Live. And, if you like, send this through via OSC.

I'm very stoked!

.m

[Machinate]

the [Transport] object will be sample-accurately locked to the Live tempo - take that data out, [udpsend] that shit to the other machine and *then we hope that MaxForLive on the other machine will be able to control the master transport of Live!*

[SimonPHC]

From what I understand, MfL is Max/Msp/Jitter but NOT standalone. I'm thinking you could most likely use hostsync~ to extract timing and tempo information from Live. And, if you like, send this through via OSC.

I'm very stoked!

.m

Extract, OK, because that's useful in processing audio or MIDI signals, but a MFL device on one channel that is able to influence the global transport in Live is what I'm asking for.

the [Transport] object will be sample-accurately locked to the Live tempo - take that data out, [udpsend] that shit to the other machine and *then we hope that MaxForLive on the other machine will be able to control the master transport of Live!*

Please, is this a quote?

[jeremydb]

Hi Ableton & Cycling74,

Are there options in Max For Live to influence global functions, like tempo or MIDI Clock in/out?

Will it be possible to easily sync two machines running live through a M4L patch using UDP instead of MIDI? The data rate and accuracy of network packages is much much higher then MIDI Clock, especially on a LAN, so I think this would be great!

if not: feature request!

Global set properties like tempo and song position are certainly controllable. UDP communication works fine, as well. So... I haven't tried what you're describing, but there is no reason why it won't work (although factors like network latency could make this less perfect than you might like -- I'm not claiming that you'll have sample-accurate sync between 2 machines, just that you can send control messages from one to the other).

jb

[Coupe70]

although factors like network latency could make this less perfect than you might like.

jb

can it be worse than ableton midi clock...........?

[SimonPHC]

although factors like network latency could make this less perfect than you might like.

jb

can it be worse than ableton midi clock...........?

on a LAN, like one cable connecting two laptops?
I'm not thinking about Robert Henke's Atlantic Waves, I'm thinking about "no-need-for-old-MIDI-Clock".

[unsaturated]

Hi Ableton & Cycling74,

Global set properties like tempo and song position are certainly controllable. UDP communication works fine, as well. So... I haven't tried what you're describing, but there is no reason why it won't work (although factors like network latency could make this less perfect than you might like -- I'm not claiming that you'll have sample-accurate sync between 2 machines, just that you can send control messages from one to the other).

jb

Why use UDP then? Why not use audio and a click-track to synch two machines? Like a word-clock, but for tempo. DAW's HAVE to be sample accurate on the audio output and input, and the latency ought to be constant (and low, like 3 to 10ms max).

[hoffman2k]

Hi Ableton & Cycling74,

Global set properties like tempo and song position are certainly controllable. UDP communication works fine, as well. So... I haven't tried what you're describing, but there is no reason why it won't work (although factors like network latency could make this less perfect than you might like -- I'm not claiming that you'll have sample-accurate sync between 2 machines, just that you can send control messages from one to the other).

jb

Why use UDP then? Why not use audio and a click-track to synch two machines? Like a word-clock, but for tempo. DAW's HAVE to be sample accurate on the audio output and input, and the latency ought to be constant (and low, like 3 to 10ms max).

Well why not indeed? You can use audio to transmit data.
But it still requires some processing on both ends, so the latency may be variable to how much the M4L device can handle in CPU intensive sets. Although audio is always high priority. This probably means you're best to stick to MSP signals. Hostsync~ is an MSP object, so probably not much work required for this.

But I honestly can't wrap my head around ANY sync system where people expect a one direction signal to sync multiple systems and not have at least the latency that'll make sounds phase. Unless its from a dedicated hardware clock. Like many people are using successfully in their setups now.

Anyway, my somewhat long winded point is about an idea that makes sense (to me) but has yet to be worked out. Its essentially a sync correction system and time parameter delay.

You start with letting 2 computers speak to each other. Basically a ping message that calculates an average delay time (latency + processing time) between the 2 systems.
Both systems have an atomic clock running that preferably measures as deep as nanoseconds, but milliseconds will probably work. Maybe sample time.
When the master (either laptop. Both are master and slave) starts, this start message is delayed and triggered in Live at the exact same time on both machines. So now you got 2 perfectly synced laptops, so far so good.

For tempo changes along the way, the same system applies. Messages from the master are delayed and fired on both laptops at the exact same time.
The only message that both machines require to stay in sync is a ping that updates the latency data. This ping can also check if both machines are still perfectly in sync and possibly automatically/manually adjust a tempo.
But it shouldn't be a constant adjustment that sends both systems to drift.

This all means that Transport controls need to originate from M4L devices. But thats not a big deal with the API control features.

I'm not the brightest bulb on the block, so I figure there must be some serious flaw in my theory that I'm overlooking. because the theory implies you could sync 2 computers anywhere in the world. That doesn't sound right.
I'll need to test this one over the summer, if only to find out what I overlooked.

[broc]

This all means that Transport controls need to originate from M4L devices. But thats not a big deal with the API control features.

I've experimented with the API function "start_playing" and measured variable latency around 20-50ms until Live actually starts.
So I think it's useless for synchronization.

[hoffman2k]

This all means that Transport controls need to originate from M4L devices. But thats not a big deal with the API control features.

I've experimented with the API function "start_playing" and measured variable latency around 20-50ms until Live actually starts.
So I think it's useless for synchronization.

Well there's the transport too. Not sure why i thought of the API first.

[broc]

This all means that Transport controls need to originate from M4L devices. But thats not a big deal with the API control features.

I've experimented with the API function "start_playing" and measured variable latency around 20-50ms until Live actually starts.
So I think it's useless for synchronization.

Well there's the transport too. Not sure why i thought of the API first.

But keep in mind that you can't start Live with the [transport] object as it's slaved to Live's transport by design.

[hoffman2k]

But keep in mind that you can't start Live with the [transport] object as it's slaved to Live's transport by design.

Ah well. There's the rub then I suppose.
There should definitely be a way to start Live from M4L in a way that doesn't involve unpredictable latency.
If we could control the transport with live.remote~, the latency would be the size of one sample buffer. Which is variable to your own preferences.
Man I hope we see some more M4L developments soon...

[Khazul]

Might be better off using some MIDI over IP network driver. Writing a decent fly-wheel type synchroniser in MAX that makes smooth adjustments to bring the slave into sync might keep you busy for a while