latency of send/receive predictable?
With recent tests I've noticed that the latency of send/receive seems related to Live's audio buffer size.
For example,
512 samples: ~12 ms
128 samples: ~5 ms
So in contrast to earlier versions, there is no jitter and the latency seems predictable to some degree.
Can this result be confirmed by the developers?
I've repeated the test with another setup and this time found latency near 0!
Apparently it depend somehow on the setup, in short: the latency is basically *not* predictable.
The question remains if the *maximal* latency is predictable, ie. determined by the audio buffer.
hey broc, what was your setup for the second test? (sorry for quasi thread hijack).
p.s. - i want answers to all broc's questions too.
My second test was minimal.
No audio track, just 2 MIDI tracks with M4L MIDI effect on each for sending a bang and receiving it.
Time measurement with [cpuclock].
I guess the 0 latency was achieved because in this case both tracks did run on the same thread.
But the behavior may be difficult to reproduce depending on other unknown factors.
Btw, thanks pid for your interest.
Are there any other info about send~ and receive~'s latency?
I just realized this latency by playing my double bass through Max and comparing with and without send~/receive~. The latency is pretty obvious to my ears without any measurement.
This is weird because I've been playing my bass through Max for 6 years and didn't really notice anything. I always have exactly the same settings that I loadbang.
Does this latency adds up if I have several chains of send~/receive~?
There should be a mention about that somewhere in the help file, reference or tutorials.
Florent
I think send~ receive~ pair have a latency of 1 signal vector, so if you have a large vector and a signal going through a number of these pairs you'll get a noticeable latency
example:
it is always one vector, but if it properly works in live is another question.
thanks guys,
Ok, so theoretically the latency is one vector, but in practice it is not. Am I correct?
Broc's tests above show that it is not predictable and consistent.
Why? What does it depend on?
It is one vector when the signal chain that ends in a send~ has somewhere a receive~
thanks JVKR
there were similar issues in pluggo with logic, it might be that in live it also makes a difference if you are having 2 devices in different channels or in the same. and as you already found out, the buffer size seems to matter. :)
Hey, sorry if my question sounds stupid, but what is the math to calculate the length of a vector?
For example, if my sample rate is 44.1Khz, my I/O vector size is 64 and my signal vector size is 64, what is the duration of my send~/receive~ latency?
Just trying to figure out if the latency I hear comes from those send~/receive~ pairs or from something else.
thanks
Florent
@broc::
i`ve done a lot of testing some time ago,to me send/reveive had a latency of exactly 30ms.
but maybe this imrpoved by now...
anyway, i started using udpsend/receive which also has unpredictable
latencies but far shorter ones.
another issue regarding m4l is that the entire API is NOT IN ANY WAY
timing-accurate,there`s lots of jitter all over the place with up to 30msec.
which is ,@florent ghys, when the human ear stars to recognize an echo.
thanks RBRT for the feedback
what buffer size did you use for this 30ms tests?
I have arrived to clear up some confusion! >;D
Broc's original post is about send/receive('s'/'r'), the non-signal versions(note the mention of measuring receipt of 'bang').
(When RBRT is addressing Broc, he is making a suggestion about udp offering better latency than the non-signal versions.)
When FlorentGhys rebumped this thread 3 years later, he's now talking about send~/receive~ pairs, the signal-version(where the vector size, as mentioned by others, comes into play).
FlorentGhys can ignore RBRT's findings if he is more interested the latency of the signal-versions.
(...in regular max/MSP, send~/receive~ only added vector of latency when placed in feedback loop, so the pluggo/m4l thing is likely a protection for plugin-style operation...)
I am done now. You may return to your regularly scheduled programming.
Thanks, this is a very good clarification and I apologize for the confusion.
@RBRT
In my experience the latency and jitter of send/receive vs. udpsend/receive are basically the same where the maximum depends on Live's audio buffer size. I can confirm the general inaccuracy of API, even up to 50ms.
Anyway, it's a shame that the diverse latency issues of M4L are not clearly explained in the documentation.
@BROC::
I USED TO BE RIGHT.NOW I M ALL WRONG.
i just did the latency-test again,with max 6.1.9 and live 9.1.5.
there is NO latency with send/receive from one M4L-device to the other anymore.seems someone has fixed this.
I ' m very very sure it used to be 30msec.maybe I should also check the LOM for latencies again..
bye bye udpsend, hello send/reveive.
Interesting. What was your setup for the latency test?
Did you try sender and receiver on the same track or different tracks?
I tried your test (on Live8, Max5) and also got NO latency with send/receive.
Apparently the behaviour was changed already in earlier versions (see also my 2nd post on this thread).
But I still wonder if it's true for every possible configuration.
Any comment from the developers would be much appreciated.
What about sending signals between patches on the same track? Is there a way to compensate latency?
I tried sending from patch A to the immediately following patch B, and sending float has some latency, as well as sending audio. I tried using a third patch, because maybe the sending from A and B have the same latency when reaching C, but it didn't work, they have different as far as I can tell.
I also tried sending the signal (instead the float) form A to B, then delaying patch B's own signal, but it seem to me that the delay~ can only delay a signal by 512 samples, which is weird.
I'm a beginner, so any info or clearing things up in my head is appreciated.
@WINGEDFINGER: hmm I cant reproduce with my patch regarding the float...I am not talking about audio here in general,only about messages.audio will have some sort of delay and I dont think that
can be changed..
did U use the patch I set up?
@BROC: I just checked about LIVE's API again,and it seems somebody has been working on it.I get
only 10 msec of delay now for starting LIVE's transport from M4L.this used to be 30 msec.
I totally agree with you that timing inaccuracies intoduced by the LOM should be documented..
cheers --rbrt
Hey there, in order to have one midi track sending midi notes to several „layer children tracks“ with instruments on them, I am using s/r. The “Master“ track has a send device on it (midiin —> s chan1) and the midi tracks with the instruments each have a recieve device on them (s chan1 —> midiout).
When starting the clip on the “master“ track and havin abletons metronom playing aswell, the instrument tracks are randomly off grid/quantisation of the metronom (getting randomly long delayed, due to latency I guess).
I am using Ableton Live 10.
Is there any way known by now, to get rid of the latency issues, when using s/r over multiple tracks?
thanks,
Malte
it's a pity to hear this issue still hasn't been taken care of in Live10/Max8.
from what i remember (i think by reading posts on this thread some time ago), it's not advisable to use send/receive for routing audio/midi in maxforlive unless you really don't care about timing issues.
in your case, i would suggest to use LOM messages for the routing instead of S/R.
You know that you can address other tracks from M4L in Live 10 now correct, both audio and midi.
@Malte I am actually getting super good results in the exact same situation. Do you have a small buffer size in your preferences? M4L runs in audio in interrupt so you better have a small i/o buffer size
there is also an easy workaround if you want to bypass Max's send and receive objects: use Ableton's built-in routings in which all your "children" tracks receive from the main track. Then from your main track assign a midi value such as pitch bend, cc, program change... to each midi note with the midiformat object, and then on your children track, unpack and select. Something like this:
@Florent GHYS - M4L doesn't seem to have the option to change the buffer size, which makes sense to me as I would think the host would determine that. I'm doing a super simple one MIDI track transposes another setup and getting variable and high latency values. I thought a workaround could be the track delay compensation and just have the master track have negative delay so it starts earlier in playback but that doesn't seem to affect max messages. 15 MS is definitely too much
hey, yes buffer size is determined in Ableton's preferences
the negative track delay + pipe within your M4L patch should be working, I'm doing it all the time
@Florent GHYS no the track delay definitely isn't affecting the control side of things. It does the control stuff then delays the audio it looks like. In a set with nothing in it, the timing looks to show no delay also. However that's not a real world situation. Also, this would be something to share. I can't require that the user set their buffer size in Ableton for it to work. Other ideas ?
How fast and consistent is device mapping controls ? Some use audio rate. Its messy, but is there a workaround to talk between devices trying to do simple things like note transposition using a different method ?
The above tests are lying .... I plopped that on the og transposer device and it measured 0 ms between received notes on the native track and the sent ones from the master track. However even at 5ms delay the native track will outpace the sent notes sometimes as I can hear (just bouncing back and forth an half notes transposing a semitone and back down. So I can't even diagnose it. I re-read through all the comments where people thought there wasn't latency anymore and I suspect it may be because timer is lying.
Just did again some tests with send/receive and noticed that the latency depends on the actual configuration. When moving the send/receive devices around on different tracks, I got either latency 0 or x, where x depends on Live's audio buffer size. So the occurrence of latency is not predictable but the possible maximum value.
@broc So we are saying that faster than audio buffer is possible, and it won't exceed this ? If using clunky live.remote / LOM methods is that always at buffer latency ? I see discussion in this thread of variability there and I'm wondering if I should even be exploring that.
The latency of live.remote/live.object when used with Max messages is subject to the activity in Live's UI thread. So it can be higher than with send/receive.
@Florent Ghys : thank you so much for the PitchBend trick to route MIDI from different tracks !
Hi, I reviving this topic, trying to see if there is any latency when using send/receive between m4l devices.
I made these two devices to testify there is any latency. It seems to prove that there is no latency, as the value displayed by the receiver is always the same as the sender.
Am I correct, or is my way of testing wrong ?
I made these two devices to testify there is any latency. It seems to prove that there is no latency, as the value displayed by the receiver is always the same as the sender.
Is this true? Is there really no latency between send receive now?
I did @CHAPELIER FOU's test, and I don't see any latency.
IF this is true, then this is a big deal combined with this from Live 12's release notes:
When a Max for Live modulation device comes before its modulation target in the device chain, the modulation signal will no longer be delayed by a buffer.
If there is really no more latency between send/receive, then one could send modulation signals to devices anywhere in a Live set with zero latency. live.remote~ objects could sit in a Max for Live device in the target device chain, and they could receive their source signal from a ~sig object which receives its signal from a (hopefully) zero-latency receive object, which receives from a send object anywhere else in a Live set.
I REALLY want some clarity on this.
from how it reads it would still work only within the same rack, and when it is before the targets there.
this somehow fits to the proposal of @broc from 2011 regarding processing cores.
from how it reads it would still work only within the same rack, and when it is before the targets there.
But...that is only half of what I am trying to convey.
Consider this:
You have a live.remote~ device in the same rack - before its target. Per the documentation, there is no latency. IIRC I have confirmed that.
Now, consider that you have said live.remote~ receiving from a ~sig object, and the ~sig object receives from a receive object, and the receive object receives from a send object on a different track. Here is a diagram:
Track 1
send Track2Receiver
Track 2
receive Track2Receiver->sig~->live.remote~->parameter on adjacent right side device
Since there is no latency in the live.remote~ transmission, then IF there is no latency in the send/receive transmission, then there is no latency.
So, we need some clarity on whether and when there is latency in send/receive transmissions. If there is not, then we have a golden solution for zero-latency cross-track mapping devices.
i can totally follow you, you do not want your master remote plug-in work only for one channel, you need it to work globally, just like in max.
that´s what i am doing in good old pluggo runtime since stone age.
in max4life, which is not just another from of the max runtime, your best bet is probably to systematically try these things out yourself, as nobody seems to know it.
When I test send/receive (in Max for Live, sending across devices and tracks) I get a latency of 0 when measuring in ticks and 0.03 when measuring with cpuclock. Those values are much lower than the latency of the buffer, and if it works that way in all configurations, then that would be fantastic.
I have searched the forum, and there are some reports that the latency is variable and that it can go all the way up to the buffer size. But, there are many reports of the latency being consistent with my measurements.
Does anyone kindly have a definitive answer on these questions? Years ago, people have asked Cycling '74 about this in this forum, but I see no replies.
Questions please:
What is the maximum latency of send/receive?
How is the latency of send/receive set?
Is it worth contacting Cycling '74 or Ableton directly? Compared to this forum, would I have better luck getting a response?
The manual is not helpful. It says there "may be some latency."
Communication between Max for Live devices using send and receive is supported, but there may be some latency involved when sending data between devices.
it is "variable" for messages (in live), zero for signals, and one vector when there is a feedbackloop in the signal.
10 hours later: no, nonsense. it is one vector for the signal s/r objects.
I have gone ahead and emailed support.
It would be great to finally get some clarity on this.
Please post info here if you get an answer !
Below are the questions I sent to support and their responses.
What is the maximum latency of send/receive?
How is the latency of send/receive calculated?
Can we rely on the latency of send/receive being under a certain threshold?
Is the documentation about this still up to date?
Here is Cycling '74's response:
Thanks for contacting us. send and receive latency in the context of Max for Live is determined by Live's order of operations (which could change in the future).
On a single Live track, all devices are computed sequentially, and should therefore not be subject to any latency. However, when multiple tracks are in use, the order of operations becomes more complex. Live might choose any track to execute first. In this case, sending data to a device on a track that has already been executed, will result in latency.
Things get even more complex when you have a specific device that introduces different latency, as some M4L devices do. The exact outcome in latency when sending data between a track with a latency inducing device and a track without, is not fixed as there are too many variables.
With all of this in mind, the only instance where we can guarantee zero latency is if you send data downstream from one device to another on the same track.
If data is sent across the Live set, the amount of latency is unpredictable and might change if Live's order of operations changes.
Here is a follow up question I asked:
Do global shared objects like arrays also work the same way? Like, if I update a global shared array from one track, could I access it from another track with confidence that the latency would be a fixed value?
Here is Cycling '74's response:
There is not a reliable maximum latency value. The only way to truly know the amount of latency for a specific Live set is to measure it individually by time-stamping when the send is sent, and when the receive is received.
Yes, global shared objects work in the same way where latency is determined by Live's order of operations.