like anything else, it would only cost performance if it were being used?
Fix the issue where it is created isn’t a realistic solution as that is depending on hundreds of plugin makers to revise their plugin design.
This is a simple solution to a simple problem, I doubt it would cost much performance if any at all… at least no more than adding another plugin to gainstage.
need to go grab a coffee and walk the dog ttyl
It is a workaround for someone else’s problem. (Ok, steibberg need to fix their plugins).
It’s not really someone else’s problem. It’s the users problem and it’s just how some things are designed and a lack of consistency in protocol and universal approach (which perhaps should have been established by Steinberg) has resulted in this. For example,
It’s a practicality, especially in the digital world emulating the analog world. Many plugins are 1:1 emulations to analog, yes many analog hardware have output trim - but many also have colourations associated with the output level. Adding an additional output trim would no longer be an emulation - hence in the analog world, someone gain matching on a console with a return level, or the fader. In this context the console is - Cubase. It’s not practical to use the fader in this case, because in the digital world we are using more inserts and bigger chains than in the analog world, plus we are contending with resolution loss on faders.
There actually other instances for when this could be useful. The the user is starting with a source material that is low in volume and they have already initiated some plugins with threshold settings, and they are already utilizing the output on the plugin to gain match… but… they want the signal to be hotter going into the input of the next plugin.
So I don’t really get your approach to this topic and @steve liking it - “this is a problem, but it’s somebody elses problem so I’m not going to allow an easy solution to this problem, even though the user suffers the consequence of this problem, and relying on others to fix the problem will probably never result in the problem getting fixed”
It is a very small problem compared to aliasing effects for example. I dont mind if they do hack to solve your issue if it does not have any performance impact for the rest of us. But I dont think that is the case. And if they are going to do workaround for poor plugins there are a lot better and more generic ways than have a special function knob for a non real problem.
It’s the accumulation of small problems that should be focused on imo, they are the bane of my existence and my personal mission on these forums.
There’s a lot of plugins that I rely on this 0dbfs soft-clipping effects in my production and mix work, and I know there are many others out there… It’s a big problem to always be having to add gain-staging plugs just to cut 6 or 12db - - it’s really silly when you think about it! To even have to spend 5-10 seconds doing this.
It’s actually a - real - problem.
Even my fancy gainstaging plugin isn’t really a solution because typically, you encapsulate the entire plugin chain, and not between every plugin.
Gainstaging was something I ignored for a long time, my mixes improved tenfold when I started gainstaging properly.
0dbfs does not really exist in VST world. It is a fix bit thing, cubase is using floating point for all audio data that goes in or out of a plugin. It’s nominal scale is -1.0 to 1.0, but there is about 385 dB headroom in 32 bit FP and 3000dB for 64 bit. Anything else is just a bugbear.
I already know this, this is irrelevant to what we’re talking about though
edit
I’m not actually sure that is entirely true, 0dbfs does exist in the VST digital world if you are emulating analog
Not really, it’s relevant to how it can be solved if it need to solved. If something is not working with plugins it would be good if Steinberg did some clarifications in the VST-SDK if many vendors have problems with it.
I’m failing to see the relevance. We’re talking about volume going up, without utilities for volume to go back down. What’s happening in the technical background, doesn’t really mater.
I believe the headroom is dependent on the plugin next in the chain. different plugins have different headroom… they definitely don’t have 385db of head room. If that were a thing, there would never be plugin clipping which there clearly is.
hi gents (and ladies?)
can I point you towards:
It’s a totally valid feature request even if you don’t agree on the technicalities… it’s ok to disagree 
You can get clipping when your audio need to be converted to fix bit, or when the programmer has non linear function that does that intentionally. And that is why there is nominal level of 1.0 that is the level where it will be mapped to max fix bit when it time for the final output.
Alright well, either way, sort of irrelevant to the FR… but I do appreciate the technical background details you know about.
In regards to my gender,
That’s not an argument.
Personally I think if a plugin has a specific feature like driving the signal against the output circuit/stage for non-linear analog modeled distortion, it should have a separate and native final output level control as well.
DAW could include host specific ‘auxiliary’ nodes (‘under-the-hood’ plugins) between the ‘main’ nodes (‘actual’ plugins) in the audio network graph, and then for example implement these auxiliary controls, such as separate dry/wet mix, input/output levels etc, in the main plugin GUI window frame. Not sure if this is how it’s done with DAWs, but in principle this is how telecommunications network control/maintenance tasks are handled between ‘links’/‘towers’. To my knowledge at least Ableton Live, FL Studio and REAPER offer such extra ‘host specific’ controls for individual plugins, so I guess it’s doable/solvable in efficient manner in the DAW world as well.
The issue here, is that the final output stage, is also being utilized to drive non-linear distortion/effects. And also of course, many hardware pieces have a output transformer that saturates as it is utilized more (like Neve). So it’s sometimes not only the input.
I’d actually be against Dry/Wet mix nodes on each insert, as I think it’s an annoying signal management mess especially if exchanging projects with someone else, and also, any plugin that makes sense to have dry-wet already has it.
So I’d be fine with only an Output trim node in the Cubase VST frame.