Render the mixer levels in a dB FS scale

[michaelgregorius]

Adds the option to render the mixer levels in dB FS. By default this option is disabled so that classes which inherit from Fader are not affected by this change. However, in the code of the FxMixerView this feature is enabled so that the mixer shows the levels in dB FS.

The ability to render in dB FS is exported as a property so that it can also be set in a style sheet (not used as of now). The new property is called levelsDisplayedInDBFS.

Showing the levels in dB FS (which is a logarithmic scale) gives a less "fidgety" impression when the levels are moving. This can be seen in the following movies, especially when channel "FX 1" goes into clipping towards the end of the movies.

Linear levels	Levels in dB FS
(-40 dB, 0.8 dB)	(-40 dB, 12 dB)

The new mixer shows a range of (-40 dB, 12 dB). This provides the user with more insight into how much a channel goes into clipping. The previous implementation corresponded to a range of (-40 dB, 0.8 dB) which pretty much only showed you that you are clipping. This is also best illustrated towards the end of the movies. The linear levels just bounce against the ceiling when clipping while the logarithmic levels have still some headroom.

[Umcaruje]

This is awesome 👍 Though a DB readout somewhere in the mixer would also be extremely useful, so we know how much exactly we are clipping.

[IvanMaldonado]

Please do! this is something very helpful 👍

[michaelgregorius]

I am currently working on breaking the graphical elements of the mixer channels into separate widgets to make it easier to resize the strips when the mixer windows is resized. In my opinion this step is necessary to be able to render the level meters at bigger sizes which in turn is necessary to be able to display all the additional information that might be useful:

• Lines that indicate the levels
• A dB read out for of the max value
• A clipping indicator

It's not possible to put all that additional information into the current rather tiny level meters. However, I guess it will take some time.

[michaelgregorius]

@LMMS/developers Is this one OK to merge? I think all the other proposed changes should be handled in separate pull requests.

[Umcaruje]

@LMMS/developers Is this one OK to merge? I think all the other proposed changes should be handled in separate pull requests.

Sounds good to me.

One thing though: I think you should make the faders over at the Equalizer plugin use dbFS too.

[Fastigium]

@michaelgregorius Can you comment a bit on the similarities and differences between this change and the "Display volume as dBV" option that's available in Settings? Would it make sense to allow the user to switch between dBFS and linear scales?

[michaelgregorius]

@Umcaruje I have tried to switch the Equalizer faders to use db FS as well but it gives some unexpected results so I'd rather leave it to the author(s) of the Equalizer plugin to adjust it.

The problem is that playing a signal through channel strip "FX 1" gives other readings than shown in the "In" fader of the EQ although both faders are at unity gain (after having switched them to dB FS). The discrepancy can be seen here:

Some minutes ago I have reported issue #2703 which might indicate a general problem with the data that's fed to the EQ faders.

[michaelgregorius]

@Fastigium The option "Display volume as dBV" seems to rather affect the data displayed by the faders, e.g. the tool tips, but it does not affect how the level meters render the incoming signal. For example when you double click a fader it will display a dialog where you can enter a new value. If you have the option "Display volume as dBV" selected it will ask you to enter a value in dBV.

Side note: I think that all references to "dBV" are wrong anyway because there is no voltage to measure in LMMS in the first place. All that you can measure is the relative value to a full signal. When using a float representation the convention is that the full signal is represented by the values 1.0 and -1.0 respectively.

I don't think that it makes sense to show linear levels because all other DAWs show the levels in dB FS so that's what users are used to. I'd assume that if you ask some mixing engineer which of the two movies above looked more familiar to them then all of them would choose the right one with the display in dB FS. That's also the reason why I did not couple the rendering of the meters to the option "Display volume as dBV" but always render in dB FS. The old rendering in linear levels was just kept so that other components like for example the EQ show the same behaviour as before. It also enables a gradual switch for other components.

[Fastigium]

@michaelgregorius Makes sense, thanks for the explanation! Code looks 👍 to me, but I'd prefer you wait with merging it until the visual changes to the level meters are ready, too. RC2 is just around the corner, and I fear changing the 0dB height without visual indication might confuse/annoy users.

[Umcaruje]

Cross-posting from HDDigitizerMusic#22

This is my idea on how the fader dB readouts should look like. I think a full line with a distinctive clipping marking will help a lot with the metering issues that currently exist in LMMS. Now, I think this also should be handled by CSS (cc @RebeccaDeField) so we don't end up doing some pixel trickery. But if that's too much work, I guess some pixel trickery wouldn't be that hard.

[tresf]

I think this also should be handled by CSS

As one property or two?

Not sure if Qt supports webkit gradients, but if it does perhaps...

foo {
   height: 400px;
   background: -webkit-gradient(linear, left top, 0 300px, from(#fff), to(#eee));
}

... or

foo {
   height: 400px;    
   background: -webkit-gradient(linear, left top, left bottom, from(#fff), to(#eee), color-stop(0.75, #eee));
}

borrowed from http://stackoverflow.com/a/5016885/3196753.

[Umcaruje]

@tresf Qt doesn't support webkit gradients, and has its own syntax for them. I was thinking about having 2 q properties, one for the green and one for the red part.

[tresf]

👍

[michaelgregorius]

I think we should design the css in such a way that scaling the faders is supported, i.e. if you change the height of the mixer window some of the space will be allocated to the faders which change in size accordingly.

So I'd propose something like the following (linear gradient copied from some other CSS, doesn't make sense with regards to the colors):

bar {
  qproperty-faderColors: qlineargradient(spread:reflect, x1:0, y1:0, x2:0, y2:0.5, stop:0 #5b6571, stop:0.75 #7b838d, stop:1 #7b838d );
  qproperty-zeroDBLine: 0.75
}

In this case the zero DB line is always given as a ratio with regards to the representation of the fader colors. I have used qproperty because in my opinion we should not use the background property to specify the colors of the faders because the widget should still have a "real" background that might shine through in some places (depending on how the faders are rendered).

[Umcaruje]

@michaelgregorius I don't think the users should be able to define where the 0db line is, I think the ratio should be hardcoded. But the reason I think there should be 2 colors, is because I don't think there should be a gradient between the red and the green part. I think it should be a 'hard' gradient-less red line. so for example:

Fader {
     qproperty-faderColor: qlineargradient(spread:reflect, x1:0, y1:0, x2:0, y2:0.5, stop:0 #5b6571, stop:0.75 #7b838d, stop:1 #7b838d );
     qproperty-clippingColor: red;
}

and anything that is 0db or over is in that color. Now, some DAW's are even more drastic. Bitwig, for example, paints the whole dB readout red when you're clipping.

[IvanMaldonado]

Why not just adding a led indicator that turns on each time you clip, and you right-click it and press "reset" to remove the indication (like ardour).

[Wallacoloo]

A resettable LED sounds really unusable to me. I don't think that
monitoring the signal level should require any active participation on the
user's end. If one wants something similar to a reset button, I would
recommend a peak bar like FL Studio has (I think lmms might already have it
too).

To be honest, for most applications, if you're clipping and you can't
hear the effects of it, then the clipping isn't really a bad thing. So a
visual trigger seems unnecessary - you'll be able to tell a bad clip by
ear. I'm not arguing against a dB scale - just against the proposed reset
button.

[tresf]

you'll be able to tell a bad clip by ear

I would tend to disagree with this statement. Often clipping is for a split second, the indicator is very valuable in my opinion.

[mikobuntu]

I find the way this works in Ardour to be quite useful, but if some devs think it will cause too much user interaction how about making the fall off time for the visual peak bar ( when it hits red ) to be increased or even to have the foreground of the whole display bar to flash red ? I can make a mockup later today to demonstrate if required.

Date: Sat, 2 Apr 2016 11:48:48 -0700
From: notifications@github.com
To: lmms@noreply.github.com
Subject: Re: [LMMS/lmms] Render the mixer levels in a dB FS scale (#2672)

A resettable LED sounds really unusable to me. I don't think that

monitoring the signal level should require any active participation on the

user's end. If one wants something similar to a reset button, I would

recommend a peak bar like FL Studio has (I think lmms might already have it

too).

To be honest, for most applications, if you're clipping and you can't

hear the effects of it, then the clipping isn't really a bad thing. So a

visual trigger seems unnecessary - you'll be able to tell a bad clip by

ear. I'm not arguing against a dB scale - just against the proposed reset

button.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub

[michaelgregorius]

I also vote for the visual resettable clipping indicator exactly because no active user participation would be necessary with such an implementation. You could just play the song and at the end you could quickly check if any of the tracks has clipped and by how much.

[Umcaruje]

@michaelgregorius what's the status on this? What is left to be done?

[michaelgregorius]

@Umcaruje The implementation status is the same as at the beginning of the conversation. Only the mixer faders are rendered in dB FS. The EQ faders are still rendered linearly due to the aforementioned discrepancies.

With regards to what's left to be done: this thread contains some discussion about other features like switching the EQ faders as well, dB readouts or clipping indicators. However, as mentioned in some other threads I am rather a fan of incremental improvements (in case most people agree that something actually is an improvement) instead of dragging on and on with other requests. So I'd propose to merge this one and handle the other aspects in separate pull requests.

[Umcaruje]

So I'd propose to merge this one and handle the other aspects in separate pull requests.

Tested this out, code looks good, merging 👍