MOTUnation.com

Hi. I come on here and complain about DP but I also just got a new Mac and can't wait to see if any problems resolve. So far it's snappier (M1 Mini) but a lot of the crap I was dealing with previously persists.

One that really irks me is the MOTU Trim plug-in. I often put one on every track when receiving mix projects that are hot going into my console. The meters within MOTU Trim on all my systems bounce out-of-sync with the music. It surely seems like a delay compensation issue and the "off-ness" gets worse with higher buffer settings. It is highly distracting and throws some GUIs down the chain (like FFTs in 3rd-party EQs) off as well. Often it doesn't, but it's still a pain.

Anyone else seeing this behavior? MOTU tech support said it could have something to do with "quantum milliseconds" but that I shouldn't touch that. Okay, I won.t. Even if the meters were off but it didn't throw its crappy delay down the line into other GUIs, I could deal with it. It's not like I mix staring at open trim plug meters.

Finally, anyone have a modern, lightweight 3rd-party trim plugin they like?

I wouldn't assume the delay what you see on the meters in the Trim plugin is a result of flawed delay compensation. It's more likely to be a result of programmers giving priority to audio processing over graphic updates.

If you put one of the several free metering plugins at some point after the channel with Trim installed, does that meter do what you expect? Does here.

If you put a series of Trim plugins on one channel and none on the other, do the two get out of sync?

No doubt the Trim plugin creates some delay as does any plugin, but why do you think this is not being managed properly by the delay compensation?

What Bays said + 1

This is a case where, clearly, the ayes do not have it.

Thanks both. I'm just reporting what I see - increased in time from (say) a kick drum hitting to the meter bouncing accordingly in Trim. Try this - maybe you'll see the same. if you don't, please let me know. And yes Bays I did that first time I noticed the issue...I did a null test and it passed. It just still bugs me esp. as it occasionally seems to mess with GUI response of 3rd-party plugs after it. Not consistently, but I've seen it happen and if I remove Trim, the GUIs of the other plugs are right again. Saw this with FabFilter Pro-Q, C2, and some UAD plugs.

To be clear I wasn't saying that the issue was flawed delay compensation, which would affect audio. The audio sync has been largely fine with a couple weird instances I'll note below. I was just stating there is repeatable and predictable proportionality between "off-ness" of the GUI and increasing buffer settings. That relationship is quite clear. You can see the meter bounce get later and later from where it's supposed to occur in time as you raise buffer settings.

Also: it didn't used to be this way. Been using DP for a long time. So it makes me nervous that if it's looking like this, is it reliable? I'm putting these trims on every track of some mix projects and I want to be sure it's working right and seeing the GUI on such a simple plug-in be so off is kind of disturbing. But yeah after the null test, for all practical purposes I'm ignoring the Trim meters. I'm still using the plug. It just freaks me out.

If anyone has an alternative that seems reliable I'm all ears. I'll be trying some but I'm on the deadline/get-new-song merry-go-round mixing so I've not been able to do proper research.

Had another look. It seems a bit odd at first, but not really an issue as fas as I can see, and in the end it is probably doing exactly what it should do. .

If Trim is the only plugins on a channel, it is showing signal at the same time as the channel meter, and as far as I can tell, at the same time as I hear it.

If there are other plugins on the channel, the Trim meters move earlier than the channel meter and before you hear it. Why would this be? Bearing in mind that any DAW does a lot of processing on an audio signal before you hear it, and that DP does a lot of pre-rendering to save CPU, etc, it seems possible that the Trim meters are showing the signal when DP is processing it, not when you hear it.

Perhaps all plugins do that? It would certainly be a lot easier to program the meter display in a plugin when the plugin is dealing with the signal, than to figure out when you are going to hear it and display it then. In fact, it is probably impossible for a plugin to get information on what happens downstream. How would it know for example, if you put the Audelay plugin on the master out?

I can't find anything to suggest Trim is doing anything to the signal other than what it is intended to do. And there really isn't any reason to pay any attention to its meter other than when initial settings are made.

Just my two cents on this:
Increasing buffer setting (I often set buffer to 4096) will lead to some delay in transport.
I mean, while tracks are playing, if I hit stop button, the tracks will still play for a significant time.

So, with high buffer setting, I'm not surprised about some delay in every display.

In case, I do need DP display and transport to be really responsive, I disable heavy plugs, set buffer low, and all is straight and fast again.