midi from Max to Live and latency
Is there a way to have more control over latency when we use Max native internal virtual midi interfaces ?
More details:
I never really needed a very accurate timing from Max to Live (always needed the opposite) as I was playing more with M4L. My current project requires to have an external max patch (for global control and live patching reasons) that fires triggers to Live. and I just noticed very bad accuracy and I'm sure it can't be possible and I miss something.
Basically, I have my external patch running, everything fine, accurate.
I fire these midi notes through "from max 1" virtual midi bus and .. OMG... timing are not accurate. If I hear the sound only, it "sounds" correct. If I record the midi flows, we can see a lot of jittering.
Before splitting everything into M4L patches, and also because splitting this would change the project, I'm asking: can we reduce this latency ? or working around it ?
I even was thinking about using network stack (I mean udp osc stuff) from Max to Live (max packing things, live unpacking things and generating midi notes to synth).
Any ideas for pointing what I miss here would be appreciated.
Julien
I have experienced similar problems (though they are faaaaar worse in Pure Data) – I assume you adjusted Max's I/O and Signal Vector Size correctly? I've attached two screenshots of notes generated from within a max patch and then recorded in live (via "from Max 1" port). The first screenshot uses a vector size of 32 whereas the other is set to 2048.
IAC Driver seems even more accurate in my case (I mean in this project).. which sounds weird!
Yes for the vector size etc. Thanks a lot. I checked that too.
No. The only way "seems" (as I don't even know, for this specific project) to do everything in Live.
Or everything in Max (but I basically wanted to record MIDI output from Max somewhere... and yes, Actually, I could collect my midiflows in Max, export them as MIDI, create midi clips with these etc).
I splitted everything in many parts.
The seq~ part is in m4l devices etc.
But the timing...
for checking the timing, I'm generating triggers within a track, and record from another one. which could induce (maybe) latency too. But I'm quite trusty with the method as a clip playing in a track, and another track recording is a SOLID method.
here is a small example with only a very small sequencer.
I fill it with events : many integer "1", evenly spaced.
I have that phasor, locked on the Live transport.
I start the transport, and I check the thing.
I record and I check the midi notes. Some would say "come on guy, that's already good". Yes. that's not so bad. but...
Few other ideas:
- even if it cut my process into too many parts: generating midi clips directly from the process that feed the seq (here it is simple but I have very weird non linear, chaotic, gauss distrib things) ... but it would be a live things.
- using techno~ ?
- don't use live (all in max, recording my 8 channels directly)
hey julien,
i'm not too knowledgeable if it comes to all this vector-size-stuff, but i think your bottleneck is the part of the patch where you enter the message domain (seq~ —> sel 1)... i think this is again subject to your vector- , or possible your buffer size in live. did you try lowering live's buffer size to something like 32 samples to check if the fluctuation in timing becomes less?
edit: i haven't fiddled around with it, but thomas once approached to zero the latency when intercommunicating midi. maybe his approach can help you out: https://maxforlive.com/library/device/3626/zero-latency-midi-router-sender
vector in max for live = vector in live as live is the one who handles the dsp.
and I used 32 samples as the buffer size (minimum possible here), even if I'm doubtful about it.
the example is for things between max for live devices, it is not my case.
I had max outside of live, sending midi notes to live itself.
the clip generation can be nice but it is really not ok as I want to use it for recording live and with live manipulation on midi flows etc.