midiin ignoring Ableton's track delay settings?
It seems midiin is ignoring Ableton's track delay settings. Is there any way around this?
I will explain.
On a basic level, I want a M4L MIDI effect on Track 1 to change a dial on Track 2 based on specific MIDI notes coming from Track 1. For example, if note 60 comes in on Track 1, then set a Pitch device on Track 2 to a certain value. Then, on Track 3, I want to record the output of Track 2's effected MIDI.
Everything is working, except (presumably due to latency), the Pitch device is changing at the same time or later than MIDI note on Track 2. So, the Pitch device is effectively late. The obvious solution seems to be to set a negative track delay on Track 1. When I do that and print the MIDI to another track, I can confirm that the MIDI on Track 1 is being negatively delayed; however, even with that negative track delay, the problem remains.
What seems to be happening is the M4L MIDI effect is receiving its MIDI data before the negative track delay setting is applied. I.e., M4L MIDI input ignores Ableton's track delay settings.
Yes, I played around with setting Track 2's MIDI input to "Post Mixer."
Yes, I am using live.remote~ at signal level and not inside of JavaScript.
Is M4L ignoring Ableton's MIDI track delay settings?
Is there any way to send MIDI to a M4L device "early" or have some kind of MIDI lookahead?
I want to avoid MIDI loopback.
Many thanks for the support.
I can attest the what the track delay affects is imperfect. For what it's worth, I wound up just putting audio delay devices in line on my audio tracks and using that, and it's much more reliable.
Thanks for the reply, but I need a negative delay, and I do not think audio delay devices will help.
if you have events A and B with some latency of A, and you want to ensure A to be earlier than B you need to delay B according to the latency. In your case it means to delay the note event which can easily be done with [pipe].
But to avoid the latency problem of live.remote~ you may instead use CC messages to control the Pitch device and send them just before the note.
Hi Broc,
Thanks for the reply.
if you have events A and B with some latency of A, and you want to ensure A to be earlier than B you need to delay B according to the latency.
This is correct.
I got it working, and I do not think there is any issue with Live or M4L.
For posterity and because it is interesting, here is what I did.
I went back to an early prototype of my project I did with MIDI remote scripts where I had to deal with the same issue. The solution is - as you said - to delay the target MIDI note events, so that they are fired just after the Pitch effect I want to effect them. The trick is to then negatively delay the target MIDI note events further downstream so that they are back in time again.
To illustrate, specifically, here is how to do it in the context of the OP:
Use three tracks. Assume the audio device's input latency is 7ms.
Track 1: Contains the MFL effect and fires the control MIDI notes received by the M4L effect. Track delay: 0.
Track 2: Contains the source MIDI notes. Track delay: 7ms.
Track 3. Contains the Pitch effect. Receives MIDI input from Track 2. Track delay -7ms.
Track 2 is delaying the MIDI notes so that they hit Track 3 after the Pitch effect is controlled. Then, Track 3 simply shifts those notes back to their original location.
It works perfectly. I verified by printing the output of Track 3 to Track 4 under various conditions. Since latency we are dealing with here is fixed (it is the audio device's input latency), we need not worry about adjusting our track delay unless we change our audio device buffer. Variable/plugin latency is no issue with Reduced Latency While Monitoring on or off.
It is crazy how effective Ableton's track delays work for this.
Being able to use M4L to control Live's parameters with MIDI notes and CCs and zero effective latency is insanely powerful.
Very interesting solution! But are you really sure that the latency is fixed?
I guess another way to say it is the variable/plugin latency is not a problem here, for it is compensated properly by Live. I have tested that exhaustively. So, effectively, we need only worry about the fixed audio device input latency.
IIRC, I read a Cycling '74 employee say in this forum:
The latency of live.remote~ when used with an audio signal for control is a set number of samples, I forget exactly what it is, something like a buffer + 64.
That comports with my testing.
But to avoid the latency problem of live.remote~ you may instead use CC messages to control the Pitch device and send them just before the note.
In this case, you would still be dealing with the audio buffer latency, so might as well use live.remote~. And in either case, I think you would need to do the trick I explained above if precise timing matters.
It would be cool if Ableton could automatically compensate for the live.remote~ latency, which would presumably obviate the need for the above trick. I tried adding a fixed latency value in my MFL device, but that was no help.
Unfortunately the latency of live.remote~ is not explained in the documentation. But from earlier discussions on the forum (also with cycling people) and my own tests it has been confirmed that the latency is relative to the size of Live's audio buffer and variable within the given range. I guess that live.remote~ uses an audio buffer for the communication which would explain this behavior.