Feature Request: VST Gain Trim: Should the base VST frame protocol have gain trim? Yes!

[vncvr]

I encounter many plugins that have gain-sensitive effects but no output trim. For example “when warmth set %100 plugin level cannot exceed 0dbfs” which encourages the user to push 12db on the output, but then offers no -12db trim.

Yes, sort of bad design on their part - but this bad design seems to be so common.

Even some Steinbergs plugins have this problem - take the Neve Portico Compressor for example, there’s a feedback mode that can be turned on in which you are suppose to use the output to change the character of the compressors effect and responsiveness. The default is even set at +4.

Just a -24db - +24db output trim as seen in the mockup, bottom right:

Sonnox Envolution is another example:

Yes, I can gain match after the plugin. Actually I use a very very handy little plugin called GainMatch by Letimix

but

The main issue comes with Saving VST Presets, and Loading Presets.

If I save this individual plugin setting - it’s not going to save my GainMatch plugin with it.

So if I’m browing presets, even when my speakers are at a nominal level - if I hit this preset mousewheeling through - I’m going to get blasted by 12db, which depending on the source material, could be a lot.

Secondly, it makes these particular types of plugins very hard to A/B the bypassed effect. If bypassed, well I’m losing 12db of gain which can’t be compared. Yes, my GainMatch plugin again solves this for me… But using GainMatch all the time a.) take times, and b.) takes two plugin slots and c.) When doing menial work and thumbing around, using ears and quickly manually getting a rough match in volume is essential.

Don’t know if this is something Cubase can add without breaking the standardized VST protocol wherein every VST plugin dev would have to rewrite their plugs???

[Dr.Strangelove]

I don’t believe this is a SB / VST spec issue.

It’s down to the plugin developers to make sure they design their plugins appropriately.

[vncvr]

Yes I agree and stated the same in my post.

The problem is… It’s just not the reality. Do we ignore reality, or do we compensate?

Why I’m not sure, maybe it’s because other DAWs - do - offer gain trim per insert?

[Dr.Strangelove]

yep - you acknowledged it and I agreed

As you say there are ways to compensate for it so it’s not really an issue. You use GainMatch but say that it’s a problem because it’s not saved as part of the ‘faulty’ plugin preset. The same applies to the ‘other DAWs’ you mention. (if that makes sense ?)

There are lots of ways that a plugin can break or mangle a signal chain (misreport latency - change phase/polarity - misapply gain - change channel order - not apply automation correctly - crash ! - etc etc etc) . At what point should the spec allow for all these and offer ‘compensations’ ?

Please feel free to request it (of course!) . Much more important things to be fixed in my opinion.

[vncvr]

@Dr.Strangelove

Much more important things to be fixed in my opinion.

Wouldn’t disagree there, I just spam everything here that pops into my head during editing.

@Dr.Strangelove

misreport latency - change phase/polarity - misapply gain - change channel order - not apply automation correctly - crash ! - etc etc etc)

However, I would tweeze out gain trim from these other problems… as gain trim isn’t so much a problem as it is a design utility both at the plugin stage, and at the DAW stage. ie some DAWs do offer dry/wet per insert (outside the VST frame) and some If I’m not mistaken do also offer Gain per insert (I’m guessing also outside the VST frame, or do DAWs have some leniency for what is tacked onto the frame/wrapper?)

[Draghe]

Just open up the pre or use the super intuitive channel window to tweak anything your little heart desires. There is nothing in other DAW that can’t be done in Cubase one way or another. Just like pro tools Cubase has a large amount of information, so much so there are courses at Berkeley for it. So just dig in and I know you will find what you are looking for before you criticize in the topic menu. The more people buy this the better it gets and these guys really do make it better. So why make your topics look like complaints. Greg Ono has a channel on YouTube that goes alive where he answers questions directly through Google Hangout. Steinberg’s customer service is definitely getting overwhelmed because of the great product but have always been top-notch.

[Dr.Strangelove]

@vncvr

Wouldn’t disagree there, I just spam everything here that pops into my head during editing.

. . . . . .

[vncvr]

Well I pretty much know Cubase from one end to the other (I have about 5 journals of notes and exploratory testing)

But your suggestion of using the Pre is a mis-solution, as this will effect the gain going into the entire plugin chain which would change everything ( edit: unless I’m dumb and have been wrong about this for how many ever years) - completely effect the sound, compression amounts, distortion amounts, clip amounts, etc, etc.

The channel window really doesn’t offer a solution to this either. The only solution is the one I’ve stated - which is to insert a gain plugin after (or automatic gain-comp before and after).

The only other solution would be to use a chainer plugin like Blue Cat Patchwork or Nugen SigMod for these particular instances where I’m adding 12db on a plugin that offers no trim (or the trim is what I’m using to add 12db gain because it has colour-effect) and then using these wrapper plugins to save my +12db presets

@Draghe

So why make your topics look like complaints.

The more efficient and logical the workflow, working out some of these details at the core level, the more people - will - buy this program.

A big asset working with Cubase is MediaBay and the Preset system, archiving, etc. So tacking on gain-trim onto the VST frame would be an extra level of OCD tidiness many people might appreciate, and simplify their gain matching work ethic (which is a professional ethic)

see

Enhancing Cubase's Core Workflow Efficiency to the Power of 3 x Pi + 4th dimension

I think I really tapped into what will speed up Cubase. It’s - incredibly - important that a DAW gets in the way as little as possible between what the user wants to do, and what the end result of a task should be. Otherwise, less music is being made in the world. I’m going to do my best, to only focus on basic-core-rudimentary function. Please vote to support this workflow enhancement [Untitled-1] EDITING _ - A.) SELECT/RANGE COMBO TOOL - Further Expansion Currently in Cub…

for more “complaints”

[Draghe]

I don’t know man, I play guitar I try to make it sound as real as possible. Good luck

[vncvr]

Sweet, I play guitar to.

[vncvr]

Day after thoughts:
Even some Steinbergs plugins have this problem - take the Neve Portico Compressor for example, there’s a feedback mode that can be turned on in which you are suppose to use the output to change the character of the compressors effect and responsiveness. The default is even set at +4.

Just a -24db - +24db output trim:

edit

Amended OP

[cubace]

I dont’t think it is a good idea. The plugin then have to share memory with cubase. Now they can direct share plugin-plugin. The solution is to have a gain plugin in the chain when it is needed. But is not very user friendly. A way to solve this is to a plugin snippets. A chain of 2 or more plugins with preset that can be inserted in any plugin chain.

[vncvr]

Not sure what you mean by “share memory”?

[cubace]

Do you code in C?

[vncvr]

no, but not sure how this is different than having the DAW fader after the plugin?

And I mean, if you have to add an entire other plugin after in the next insert slot, that is going to take up memory as well?

[cubace]

yes. you need add a plugin. But consider that you need to have a check for every other insert point in the daw. And it is only needed for poor plugins. I dont think it is a good design to assume that plugins are bad. And it is not about the amount of memory it is the extra processing that more buffers needs.

[vncvr]

I think it’s a good design to realize reality mate. And the reality is, thousands of plugins are made this way. I also think it’s a good design to enable people to gainstage properly, and to avoid bad clipping within their plugin chain. It’s good design to facilitate the plethora of differently designed plugins that exist out there.

In regards to memory, I’m having trouble believing that you know for sure what you’re talking about. a gain stage would likely be a zero latency affair would it not? I mean, I have EQs that are zero latency. The Cubase channel strip has the Pre-Gain on every channel. Many other DAWs have per-insert utilities like Dry/Wet which is crossover proportional gain. Would it really alter the buffer that much? I’m not sure.

So I’m just not understanding what the issue is and how it results this in being a bad idea.

Maybe I can call @Arne_Scheffler into the thread to explain or confirm what you’re saying.

[vncvr]

Also as I already explained, I already have gainstaging plugins but it’s sort of a non-solution

-they take up insert slots
-they aren’t saved with the individual plugin preset
-they are 3rd party - prone to discontinuation, problems, lack of update support, etc
-utility wrappers, also 3rd party - prone to discontinuation, problems, lack of update support, etc

I’d sacrifice a minuscule amount of memory if what you say is true.

[cubace]

@vncvr

I think it’s a good design to realize reality mate. And the reality is, thousands of plugins are made this way. I also think it’s a good design to enable people to gainstage properly, and to avoid bad clipping within their plugin chain. It’s good design to facilitate the plethora of differently designed plugins that exist out there.

In regards to memory, I’m having trouble believing that you know for sure what you’re talking about. a gain stage would likely be a zero latency affair would it not? I mean, I have EQs that are zero latency. The Cubase channel strip has the Pre-Gain on every channel. Many other DAWs have per-insert utilities like Dry/Wet which is crossover proportional gain. Would it really alter the buffer that much? I’m not sure.

So I’m just not understanding what the issue is and how it results this in being a bad idea.

Maybe I can call @Arne_Scheffler into the thread to explain or confirm what you’re saying.

There are many plugins with many different issues. A issue container like Metaplugin would be nice though. But it need to a lot more than volume. Like oversampling. Many plugns today are totally ignoring aliasing. That would be nice if cubase could solve.

[cubace]

@vncvr

Also as I already explained, I already have gainstaging plugins but it’s sort of a non-solution

-they take up insert slots
-they aren’t saved with the individual plugin preset
-they are 3rd party - prone to discontinuation, problems, lack of update support, etc
-utility wrappers, also 3rd party - prone to discontinuation, problems, lack of update support, etc

I’d sacrifice a minuscule amount of memory if what you say is true.

It does not cost memory, it cost performance. (it cost memory too, but that’s a cost would be ok, but performance no. Fix the issue where it is created.