I'll just try to take this on in a random scattershot fashion.HCMarkus wrote: ↑Mon Jun 17, 2024 1:45 pm After hanging out with Mr. Steele today, I was thinking about the Hardware Insert issue. James explained that Insert Plugin settings are not recalled or are lost when just about any operation is performed in DP.
Although MOTU must face (and hopefully will eventually), how about pinging the DA-AD latency once, recording the required offset, and simply advancing tracks (manually or via a plugin like Precision Delay) to be processed externally, then bussing to the outboard gear and back into DP in Input Monitor mode?
Latency should be a constant as long as buffer size is not changed.
Unless you have oodles of outboard gear, it would seem setting this up would be simple enough; it could be incorporated into a template.
Thoughts?
As far as "any operation is performed in DP," I haven't sat down and quantified it. I wanted to make a definitive list and put time into testing, but to be honest, I have been a little disheartened by the situation and not yet ready to do a lot of work, submit it to MOTU, and then as many times before sit back while a bug persists for years. Granted, they have to prioritize and it just may be that most users are working completely "in the box," so they have to allocate their resources wisely. And speaking of resources, I don't think it would be unreasonable so assume that Steinberg/Yamaha, Apple, and Avid have deeper pockets and more resources than MOTU. MOTU probably must be more strategic by necessity.
It seems the Hardware Insert Plugin (hereafter "HIP") will lose the connection to the analog I/O when it is:
• dragged from one insert to another on the same track
• dragged from an insert on one track to an insert on another track
• a software plugin is inserted in an insert prior to the hardware insert plugin.
There are probably some other situations where this occurs as well. I haven't really sat down to test all of this.
This should be true... especially when dealing with purely analog outboard gear. Once a signal enters the input of an analog processor, the signal is moving at the speed of light. So there is no latency on something like an analog hardware compressor. For example, my 76F latency offset is 48 samples give or take. I say "give or take" because the "ping" of the HIP can return different values sometimes. But any latency is solely due to the time it takes to go through the D>A conversion and out an analog output ("send") on my 828es, and then be converted back into analog by the A>D on the input ("return").Latency should be a constant as long as buffer size is not changed.
One strange aside here that I have not figured out, is that DP's HIP will ping about 48 samples round trip latency on the mono send/return to my 76D compressor, yet it returns 78 samples on the stereo send/return to my AudioScape Buss Comp. I don't understand why it should be any different? But that's what DP does when it's on my Master Fader track.
On the other hand, if you're using an outboard digital processor *connected via analog*, you're going to get not only the round trip latency, but the latency caused by the units own A>D and D>A conversion, plus whatever time its CPU takes to do the audio processing. So it will be a higher number of latency and can even change... for example a simple reverb might require less processing than a more complex reverb, hence the CPU will need more time to process the digital audio.
But for the sake of discussion, if we are talking about outboard processors that will always have the same amount of latency, the way Pro Tools and Cubase do this seems much more elegant. Both of them have you configure the external processor *once* in an I/O window. You set up the analog ins/outs and then enter a latency figure and then it's available in all projects as a plugin, by name. No "pinging" needed at that point and it never loses contact with its physical inputs/outputs or forgets the latency figure. Another interesting thing is that Pro Tools requires you to enter the latency in milliseconds. At first I didn't understand. Why not enter samples? Once I learned why, it was glaringly obvious: you might change sample rates. 48 samples at 48k is a shorter period of time than 48 samples at 44.1k.
My problem is that I *don't* have oodles of outboard gear and as such, you're likely to use a workflow in which you insert a hardware compressor on a vocal, dial it in just right and then bounce because you want to use that hardware compressor on a different track. So you will end up adding HIP to a track... getting it right... printing... then bypassing it and repeating on another track.Unless you have oodles of outboard gear, it would seem setting this up would be simple enough; it could be incorporated into a template.
But I have been thinking of some other possible workarounds:
First for the problem of moving the HIP and losing connection to the hardware I/O. You can save a preset in DP's plugin windows. It may be possible to restore the connecting by choosing a preset that changes the I/O assignments, then choosing the proper one again. This might be a little faster than going into the Send and Return pop ups and changing each to something else and back again.
Second, for the problem of forgetting latency:
?...how about pinging the DA-AD latency once, recording the required offset, and simply advancing tracks (manually or via a plugin like Precision Delay) to be processed externally, then bussing to the outboard gear and back into DP in Input Monitor mode
This was very interesting, and it caused me to think of an alternate and possibly more convenient solution (until MOTU can fix this). I remembered there used to be a plugin that I believe was called "latency fixer." (I'm going to go looking for it to see if it's still available and supported. It was freeware as I recall.).
Update: Found it! Probably needs Rosetta. I'll be doing some testing.
https://www.expert-sleepers.co.uk/latencyfixer.html
IIRC, this plugin did one thing: it occupied an insert and reported a user defined latency to the host DAW, even though it wasn't doing any processing. That allowed you to effectively shift tracks earlier without actually moving the soundbites themselves.
In theory, if DP's HIP is not retaining my 48 sample latency offset, I could simply place an instance of latency fixer in the insert just prior to HIP, set latency fixer to 48 samples, and then leave DP's HIP at zero samples (a value it so desperately wishes to maintain... so let it!)
Then when you close and reopen projects, things should be on time, every time... like when you use Pro Tools, Logic, Cubase or any other Mac DAW besides DP. (Okay... that last part was unnecessary... sorry!) I'll explore this last potential workaround and report back. Although I'm becoming weary of using that word: "workaround."
Reported both to MOTU.
