Inconsistent Gain Handling - Feedback Welcome

Description


The working point of non linear plugins like many distortions, etc, are all over the place. Some TAP plugins use -20dBFS (decibels relative to full scale), some others like the GxSD1 or the tube screamer or GxQuack seem to expect signals much closer to 0dBFS. This makes using these plugins without having to almost clip the input stage of the MOD hard.

As an example on the loops I have to jump through to get a usable high gain sound from GxSD1: I set the input stage of the mod to hit the yellow peak only occasionally (-12dBFS). Then inside the pedal board I need to use the Mod Gain to increase the gain, then at the end of the pedalboard I need to use another Mod Gain to lower it back to a non clipping range.

How to reproduce


  1. Try to get a high gain sound from the MOD Duo using e.g. GxSD1

Expected/suggested solution


The standard for ā€œnormalā€ signals in the digital domain seems to be -18dBFS (EBU and BBC), so taking this into account I propose:

  1. Instruct users to setup their instruments and the mod input stage to hit -12dBFS (the yellow peak LED blinks occasionally). This should be a good compromise with respect to the signal noise ratio of the MOD
  2. Lower the digital signal by 6dB to get to -18dBFS before hitting the pedalboard
  3. Fix all non-linear plugins to have their working point at -18dBFS
  4. Do the inverse on the output stage (raise by 6db digitally)
3 Likes

iā€™ve also definitely run into level inconsistencies, but canā€™t name specific plugins at the momentā€¦ i just know that my pedalboards often have to incorporate a few Mod Gains to get reasonable gain staging throughout. i suppose this might be hard to avoid since there are a number of different developers. still,a bit more consistency would be nice.

although i like your idea of standardizing I/O levels, iā€™d be hard-pressed to keep it as low as you suggest; i tend to do things with a very wide dynamic range, and am often troubled by the background digital ā€œwhineā€ caused by the current kernel buffering implementation. so, going in/out at -12 (rather than -6, which is more what i tend to hit) represents twice as much background noise in the final signal.

thanks for your thoughts on this issueā€¦ itā€™s a good one to pay some attention to!

-12dBFS (hitting the yellow peak LED occasionally) for normal percussive chord playing gives me just a little (-4 to -3dBFS) headroom when i hit all the muted strings really hard (artificially so). I just cannot be comfortable with less headroom. Clipping while playing through a front of house with 2000 Watts of amplification is just no option for me.

1 Like

okā€¦ in then end, thatā€™s probably pretty similar to what i do. iā€™m a wind player, so i donā€™t have the percussive attacks that you have, but iā€™m also setting things up such that when i do the most extreme possible things i can maybe hit -3.

totally agreed that digital clipping is not permissable! :stuck_out_tongue_winking_eye:

I think you should report these upstream to each project, but then, unfortunately that puts the developers in a bad place because people are using these in their DAW projects and if suddenly the gain changes when they update, it breaks their projects. So some devs might simply respond with a no. The MOD team could patch them but it would be best if it comes from the plugin devs.

1 Like

The gain thing has been somewhat of an issue for me too.

On the output Iā€™ve been using the Tap Scaling Limiter (Still in unstable list) to make sure Iā€™m not overloading the D/A converters.

As for the input side I have a pretty low level going in and I boost with the gain plugin. I have no issues with noise.

As for overloading plugins within the pedalboard there is a bit of trial and error. I occasionally use a gain plugin in between plugins to cut or boost into the next plugin.

It would be nice if this was standardized but this is the downside of open source plugins. Maybe it will be something that will be required from developers for paid plugins in the future.

Haha!

Maybe itā€™s a feature to accurately emulate actual Guitar stompboxes whose gain is also all over the place in the analog worldā€¦:grin:

I think gain plugins, compression plugins, attenuation in the settings of many of the plugins themselves and for us guitarists, bassists and stickists, the presence of a volume knob on our instrument mitigates some of the need of this to go to the upstream plugin devs. I agree with @ssj71, making changes to the upstream plugins will wreak havoc outside of the sphere of the MOD.

2 Likes

yeah, iā€™m not convinced itā€™s a ~problem~, per se. as you point out, @GMaq, itā€™s kinda like the real world and everything is there that we need to deal with it. i do make liberal use of the Level Meter plugin while assembling a pedalboard, to check various points in the signal chain; a visual (i.e. bargraph) meter would be nice for easier visibility during the pedalboard dev cycle.

ā€¦and (just dreaming here) i wouldnā€™t complain about a plugin that could send bar graph output to one of the MOD displays. :slight_smile:

5 Likes

How difficult would it be at the Mod team level to add an extra control for the input gain for each pluggin, potentially hidden under the form of an optional general config file in the root filesystem. Under the hood it could just be implemented as an intermediate fixed gain jack pluggin inserted before each actual pluggin. I donā€™t know what the impact on the latency would be though.

1 Like

@Azza Yeah, that would be a workaround. The impact on latency would be zero. It just comes down to a multiplication per sample. I would go one step further: offer a pre-gain per plugin and a post-gain. While the impact on latency is zero, there would be an impact on CPU usage.

Instead of having this enabled for every plugin it would be a little bit of GUI work to selectively enable it per plugin. Think of a toggle on the plugin where you can easily turn a pre- and/or post-gain on/off.

1 Like

If it is too difficult to modify the GUI, it could rather be done via a file on the root file system, of the form

#plugginName pre-gain post-gain
pluggin1 3 -3
pluggin2 6 -2
ā€¦

When we build the pedalboard on the UI, the GUI manager looks up the table and inserts (or not) the appropriate gain units in between the jack clients. The output gain and input gain of two consecutive boxes can be automatically combined in a single one.

Regarding latency, although it is a single multiplication per sample, at the jack level, it is performed using buffers, which means that one would have potentially up to roughly twice as much jack buffers being dealt with, right ?

Well, itā€™s another buffer, but thatā€™s the magic of jack, or other buffered systems like this:

  1. The soundcard provides a buffer N of input audio while it plays back buffer N-1.

  2. Jack has time until it comes to playback of buffer N to process its complete graph of plugins/connections including any buffering between pluginsā€¦

  3. Jack is done processing buffer N and hands it to the soundcard before itā€™s time to play it back

  4. The soundcard now plays back buffer N, and hands buffer N+1 of recorded material to jack. Go to step 2

So all in all the proposed scheme just increases the CPU usage, since jack now has more work to do before being able to hand the buffer for playback to the soundcard, but it doesnā€™t increase latency

Not sure if Iā€™m completely understanding this.
If the purpose is to prevent clipping at the end of the process signal (before it gets to analog side), then a simple ā€˜finalā€™ gain fader is all that is needed.
The data type used inside the MOD is 32bit float, so clipping is not an issue there.

A per-plugin gain is surely possible.
It increases CPU usage a little bit yes, per plugin.

mind you, would a global per-plugin pre/post gain actually be more efficient (CPU-wise) than just inserting MOD Gains in a few places in any given pedalboard? it depends, of course, on the particular set of plugins youā€™re using. but MOD Gain is pretty efficient, and i donā€™t tend to need more than 3 or 4 in a board to make things ā€œplay niceā€ together.

also, good to be reminded that internal levels only matter wrt how the plugins are interacting ā€“ 32bit float eliminates clipping concerns. thanks for bringing that up, @falkTX! :slight_smile:

Iā€™m confused with your wording here.
How can it be global and per-plugin at the same time?

A post-gain after all the plugins is almost cost free.
we can even check if this gain value == 1.0, then just copy the buffers as weā€™re already doing today.

i meant ā€œglobalā€ as in: every plugin you put in a pedalboard automatically has these pre/post gain settings available. ā€¦still individually adjustable, of courseā€¦

that seemed to be the suggestion, so i just wondered whether adding that to everything you put on a pedalboard is really a good solution, since a lot of them might not need it in a given situation. itā€™s so dependent on the particular context of the pedalboard youā€™re buildingā€¦

No, the problem is more that non-linear effects (compression and distortion/overdrive/saturation/fuzz) will behave completely differently depending on how ā€œloudā€ the signal going into them is, and theyā€™re typically designed for a certain loudness but that level varies greatly between plugins. So if you have a plugin that sounds best with very loud input followed by one that wants quieter signals you end up needing a simple gain plugin in between. So with only those 2 plugins in that order you actually need a gain before the first plugin because the input from the A/D can only get so loud without clipping, then you need one in between the two to change the levels, and finally a last plugin to get the output level appropriate so it doesnā€™t clip the D/A stage. Suddenly you have 5 plugins just to use the 2.

Really though, I think it isnā€™t right to add a gain before and after each plugin. That seems like a lot of overhead and duplicated functionality for most plugins. I think most have at least a level control and if the control doesnā€™t have sufficient range or has a bad default, report it to the plugin developer.

Perhaps a nice compromise would be to make a simple gain that is much smaller (about the size of a knob) so it doesnā€™t take up much pedalboard real-estate and have a shortcut or button to add it without having to search through the library. This could make it much faster and cleaner looking to deal with plugins that donā€™t have this built in.

5 Likes

great suggestion, @ssj71!

I think most plugins that are input dependent, like fuzz/distortion/overdrive, have the gain knob which takes care of input side of the plugin. Iā€™ve only come across a couple which didnā€™t have a input/gain that didnā€™t work well enough.
The same for the output since most have a level knob for outputā€¦ only a couple of them were problematic, too quiet or too loudā€¦

I think the gain plugin can be made slimmer. maybe with a very slim sliderā€¦
I have the gain plugin in my favorites since it seems to be something I use in every pedalboard somewhere. At least in the input and outputā€¦ Actually, my default has the input and output gains already on the ready since itā€™s what I use every timeā€¦

1 Like

Hi @fps

For the Gx plugins Iā€™ll add a little switch to select the input level which the plug should expect.
This could be done without disturb the experience of existing presets.
I think about 3 levels,

Hot = 0dBFs (this is the default, currently in use)
Moderate = -6dBFs
Conservative = -12dBfs

regards
hermann

1 Like