MIDI Latency fix idea submitted to MOTU for second time

[Timeline]

The heading describes the issue.

"MIDI latency when large sessions require hi buffer settings"

Where large sessions and multiple VI's are present, Why not make a parallel software program which runs along side of DP but within DP which allows a separate buffer setting and low latency MIDI whilst monitoring playback of the original project with it's latency and operating as a no latency RAM based program for monitoring then automatically re-syncing after recording?

This seems doable and certainly an option for overdubbing MIDI without latency with large buffer settings and big almost complete sessions where an overdub is quite often required from time to time.

I have asked about this before suggesting that when a MIDI channel in selected to record ready a separate software support program is invoked on MAC and run in a live RAM state routing audio to outside sources until the recording is complete or in playback.

Even if this was done only available as a single MIDI/VI not allowing for multiple record events, it would be a start to eliminate latency in MIDI and make it more like the typical audio monitoring situation when using an IO's software for low latency monitoring.

I have paid over $2000 for DP over the years and have 40 years of pro audio experience. I would hope someone there takes my advice seriously and responds.

Sincerely,
Gary Brandt

[Shooshie]

I remember you bringing this up a year or two ago, and while it took me a little while to process what you were saying, I finally came to the realization that indeed, the idea has merit! It could be done.

However, the advent of DP 6.01 & 6.02 have made me question the need for it anymore. The latency of even a 256 buffer is usable for live recording, while 128 and even 64 are not impractical on a Mac Pro. At those buffer settings in DP 6.02, I am hardly aware of any latency in monitoring unless I set up some plugins with preset latency, such as the Waves L2 UltraMaximizer or L3 MultiMaximizer (which is set to something like an 84 ms fixed latency) I just don't use those when tracking.

That brings up the question, then, of how this would work when dealing with such plugins. Would it somehow bypass them and disable their fixed latency?

[Timeline]

I think this is what you asked Shooshie,

If you prefer not to freeze tracks like me and keep your VI's live I think larger buffers would be required on large sessions. 84ms would be difficult to play to. If it was down around 5ms that would be fine. Again, this would be for just one MIDI and one VI at a time and only engage and reroute the selected VI output to the additional IO when a MIDI track went in record. In play you would hear the overdub track re-sync, in sync with the project track. This phantom software is only for monitoring the record side of the operation.

Again, the "phantom DP software" would run outside of DP and would direct audio back through a second IO for best results or even mac "built in" if the SR is compatible. Everything but the MIDI VI that is in record would run at the latency required to keep it all going with that buffer setting and would not matter any more..

As far as plugins on the record VI, I think it would be a second instance setting you would have to put together to monitor through effects in the Phantom software or have the VI plugs repeated as a second instance in the record mode.

[pacquito]

Yes, I think this idea is great. If you plan on just recording MIDI with VIs you could boot it up in a sort of slimmed-down 'lite' mode that is more efficient and specially set up for that task. It would be good if it did bring the latency down further, and automatically boot with the appropriate buffer setup. Anything to take work with a VI setup closer to the old days of Freestyle and early Performer with external gear, when MIDI programming was very fast. And then you could later switch to the full-on production mode.

[monkey man]

Perhaps I'm missing something, but surely a single "thru tunnel" that exploits core audio, bypassing MAS, could be automatically employed for minimal single-instrument monitoring latency, no matter the project buffer settings?

I think I said something to this effect when Timeline made that post a while back. Actually, I think he did it twice, and I coughed this up on both occasions.

Kudos to the 'Liner for persisting with this.

[Timeline]

Yes, I think this idea is great. If you plan on just recording MIDI with VIs you could boot it up in a sort of slimmed-down 'lite' mode that is more efficient and specially set up for that task. It would be good if it did bring the latency down further, and automatically boot with the appropriate buffer setup. Anything to take work with a VI setup closer to the old days of Freestyle and early Performer with external gear, when MIDI programming was very fast. And then you could later switch to the full-on production mode.

Actually no. DP would work exactly the way it does but for MIDI only, a second program would launch within DP when a MIDI channel is set to input or record. Then it would be like a mini DP lite paralell instance but with monitoring features only, no effect sends, nothing else. Not sure plugs would even make sense actually but that is similar to monitoring through an IO's mixer isn't it. Maybe it could all be hidden and simply launch unseen. Even better.

"thru tunnel" is a good name MM.

This century we should beat latency issues for MIDI in DAWs and never have to think about them ever again, IMHO.

[monkey man]

LOL Yeah, Gary. Some time this century is odds-on.

One of the benefits of the through tunnel would obviously be that one needn't be aware of it. Just a little sneaky coding from the Gods of MOTU that bypasses the MAS engine for the sole purpose of passing the single audio channel (or stereo) through, processing-free, as quickly and directly as possible. This, IMHO, should be able to be applied to audio overdubs too, although one might argue that this is what the new blue monitoring button achieves. I'd disagree though, and suggest that whilst it's a more direct path, it still doesn't funnel through sans latency as it's bound to the project buffer settings. This brings us right back to my assumption that the MAS engine would have to be bypassed, something that'd likely spawn complications if all tracks were treated so, but that, IMHO, should be doable for a single input source, be it MIDI or audio. Even though Logic doesn't employ the extra layer that DP does in the form of MAS, I still suspect it bypasses its already-by-definition leaner engine for the purposes of VI and audio-record monitoring.

Lots of assumptions there, but they're logical(!), aren't they G?

[Timeline]

Yes, but I have gotten around most of my complaints from the past on audio input switching in the main mixer by turning audio through switching to OFF and monitoring through the IO's mixer. I would still would love to see an automatic (IN MIXER) switch to the IO with no latency when input or record is engaged but that idea fell on deaf ears at MOTU and they never did it. I asked for it about 10 times over the years.But yes, leaner mini engine would indeed be the little creation that would fix MIDI though if implemented as described.

[monkey man]

100% alignment here.

[Eleventh Hour Sound]

I think if MOTU could have a tear off v-Rack that would run as a separate app that would be killer.

Short of a MOTU solution, How 'bout using something like RAX (as a host) and Soundflower or Jack for audio and IAC for MIDI?