Trouble with DP Hardware Insert plugin. Anybody else?

[James Steele]

As I try to incorporate a couple of outboard compressors into my workflow, I've ran into some issues with DP's Hardware Insert plugin.

FIRST:If I move the hardware insert plugin from one insert slot (A) to another (B), even though the Send and Return still shows the same analog output and input on my 828es as selected, NEITHER work. I have to change both the output and input to a different one and then change it back for them to work again. This is true for both the send and return.

This behavior not only happens when you move the plugin to a different insert, but I just found if I close and re-open the project, the connection is also lost again. I noticed this because I just now opened a project and the vocal track that had a hardware insert plug on it was completely silent.

SECOND: If I instantiate a fresh instance of the Hardware Insert plug-in, and recall a preset that specifies the analog output and input for the Send and Return, it does not actually work and make a connection until I “tickle” it as described above, by changing both to a different intput/output and changing it back to the desired ones.

THIRD: When the Hardware Insert plug-in is put in Bypass, it is STILL SENDING AUDIO to the analog send output. It appears that the hardware insert behaves as “half-normalled” I suppose you could say. Not sure why it should keep sending audio to the external hardware in bypass? It might be a bit confusing to the user to see the meters on their outboard hardware to keep registering audio when it is supposedly “bypassed.” I understand the case might be made that maybe to preserve latency compensation this has to be done… especially if the user might choose to automate the bypass of a hardware insert? Hmmmm...

FOURTH: This has more to do with how DP does "Freeze." Does DP *always* create a stereo buss when freezing? I have a mono vocal track, with mono plugs, and a mono hardware insert plug, and when I freeze I get a STEREO file which I really don’t want. Is there a way to make freeze bounce to mono in this case?

[Phil O]

Ahh grasshopper,

Many, many moons ago when DP was young I would record a single impulse on a track, route that to an output thru a hardware unit and return to another track where I'd record the impulse. Zooming in on the impulses of the original and return track allowed me to measure the round-trip delay. I used an ancient device called a pencil to record this number.

Once I knew the latency I could simply duplicate a track, nudge the audio ahead by the appropriate number of samples and use that to send to the outboard gear, thus adjusting out any latency. They were simpler times and all was right with the universe.

Then came latency fixer. Then latency fixer went away. (Or maybe it's still out there. I don't know-one of the universe's mysteries-something to do with 32bits).

Then DP introduced the hardware insert plugin and the universe rejected it. It was doomed to never work right.

And this is why we still sometimes do things in the olden ways.

[Phil O]

So, yeah. I've never been able to get the hardware insert feature to do what it's supposed to.

Regarding Freezing.
So, if you have a mono audio track with a stereo buss as an output, freezing will create a stereo track. The only way to freeze to a mono track is to temporarily assign your original track's output to a mono buss or mono output.

Unless of course there's another way. And that is why, grasshopper, you have created this wonderful board where we can discuss the multitude of ways we have of doing things.

Your friendly neighborhood Phil

[bayswater]

Same here. Never could get the plugin to reliably detect and correct the round trip delay. Like others I measured the delay manually. But instead of shifting events, I do a submix of all the channels not affected by the round trip latency, and delay that by the number of samples in question.

[HCMarkus]

You could just put a pop at the top of the track, then line up after processing.

[James Steele]

You could just put a pop at the top of the track, then line up after processing.

Yep... I only had one time when the latency adjustment of the plug-in somehow got way out of whack. Normally it showed 40 samples when running though my WA-2A, but I did a bounce and of course the vocal that I bounce though it was delayed. I recalibrated the plugin and it said there was about 6,000 samples of latency which was really odd. Since I still had the source audio track, I just put them next to each other in the SE and zoomed in and just manually aligned the bounce by comparing the waveforms. Since that incident, it's always showed 40 samples of latency.

Overall, it seems like a good rule of thumb is to do a fresh calibration of the latency prior to freezing or bouncing.

My biggest pet peeve about the Hardware Insert plug-in is that it is losing connection to the analog I/O designated in the Send and Receive pop up menus. If I move the plug to a different insert or a different track, it will indicate the proper output and input are still selected, but it won't pass audio without changing them to a different output/input and then changing them back again. This is also the case if I close the project and re-open it.

I would like to know if I'm the only one who is experience this particular problem. Seems like something like this SHOULD have been reported to MOTU many times already, but perhaps maybe it's a feature not many people are using.

I know DP is a very complex program—any DAW is. And they have to prioritize bugs, But it seems as if there are a few nuts-and-bolts, utilitarian features like this, that are introduced and then are forgotten and never fully get the attention they need to iron out the last few tweaks. I've been putting off planning my patchbay connections, but I intend to wire it in so that I can do much of the patching "old school" in the analog domain and bypass using the Hardware Insert plugin. Just choose an analog directly as the output of a track, then have that out on my patchbay and patch through one or more analog processors and then back in to another analog input and create a target audio track recording that input. Not as elegant, but simpler. I can just manually adjust for the latency after the bounce. That's really not that hard and I suppose I could put a pop in the track, but with a vocal part if I'm a sample or two off, it's not the end of the world.

[bayswater]

I would like to know if I'm the only one who is experience this particular problem.

When I tried to use it, I didn't have this problem. Only the latency calculation errors. Possibly something related to current OS versions.

I sometimes use virtual audio and MIDI drivers to connect DP to things like Logic VIs, MixBus, and another Macs with a UAD card serving as external processors. The connections have never been a problem, and it has all worked well once I got the latency fixed. Some years ago I posted DP and Logic templates that could be used to run Logic from DP and make use of Logic VIs and effects. If you used Mixbus in it's first few versions, you'll have done the same to connect DP to Mixbus and use it's mix engine. Likely all of this is too old to work on current versions.

[James Steele]

Hmmm... maybe this is a Ventura-related thing then. I was also concerned this might be related to some sort of misconfiguration of the AVB Routing Matrix.

[James Steele]

Regarding Freezing.
So, if you have a mono audio track with a stereo buss as an output, freezing will create a stereo track. The only way to freeze to a mono track is to temporarily assign your original track's output to a mono buss or mono output.

Somehow I missed this. Indeed you are right about that.

In a way that makes sense, but in a way it doesn't. In simplistic terms... sure. Track routed to stereo output, let's bounce to stereo track. But hell.. my mono tracks are always routed to my main stereo outs. So I have to have a stereo bounce even when the source track is mono and the the effects chain is purely mono???

Maybe I'm missing something, but I'm going to try to contact MOTU and suggest maybe this could be handle more intelligently. Maybe when a user initiates a Freeze command, DP could do something like the following::

STEP 1: Is the selected track a stereo VI or stereo audio track?
If YES, open up a stereo buss and "freeze" track to stereo audio file. DONE
If NO, go to STEP 2

STEP 2: Does the track contain a mono-to-stereo plugin on an insert?
If YES, open up a stereo buss and "freeze" track to a stereo audio file. DONE
If NO, open up a mono buss and "freeze" track to a mono audio file. DONE

Granted, I'm shooting from the hip here, and I know multiple tracks can be selected, etc. but having to temporarily route the output of a mono track (that has NO mono-to-stereo effects on any inserts) out of my main stereo buss and to a arbitrary mono output to get a mono bounce, seems like a workaround that shouldn't be necessary.

[Phil O]

I guess you have to ask why one would freeze a track in the first place. With that in mind, for most situations I think what you are saying makes a lot of sense.

[James Steele]

I guess you have to ask why one would freeze a track in the first place. With that in mind, for most situations I think what you are saying makes a lot of sense.

In my specific case, it would to be to print the effect of an analog hardware compressor via the Hardware Insert plugin so I can free up the hardware for use on another track. I can’t just “add another instance” like I could if it was a software plug-in.


Sent from my iPad using Tapatalk