Render the mixer levels in a dB FS scale #2672

Merged
merged 2 commits into from Jul 10, 2016

Projects

None yet

7 participants

@michaelgregorius
Contributor

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
lmms-linearmixer lmms-dbmixer
(-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.

@michaelgregorius michaelgregorius Render the mixer levels in a dB FS scale
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".

There are now setters and getters for the min and max level.

Showing the levels in dB FS (which is a logarithmic scale) gives a less
"fidgety" impression when the levels are moving.
a8622fe
@Umcaruje
Member

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.

@michaelgregorius michaelgregorius Introduction of an init method in Fader
An init method was added to unify the initialization of the two Fader
constructors.
52ae1fe
@IvanMaldonado
Contributor

Please do! this is something very helpful 👍

@michaelgregorius
Contributor

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
Contributor

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

@Umcaruje
Member

@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
Contributor

@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
Contributor

@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:
2672-equalizer in db fs

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
Contributor

@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
Contributor

@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 Umcaruje referenced this pull request in HDDigitizerMusic/lmms-alt-theme Mar 28, 2016
Closed

The FX mixer faders #22

@Umcaruje
Member

Cross-posting from HDDigitizerMusic#22
hello its me

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
Member
tresf commented Mar 31, 2016

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
Member

@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
Member
tresf commented Apr 1, 2016

👍

@michaelgregorius
Contributor

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
Member
Umcaruje commented Apr 2, 2016

@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
Contributor

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
Member

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
Member
tresf commented Apr 2, 2016

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
Contributor

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
Contributor

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.

@tresf tresf added the in progress label Apr 23, 2016
@tresf tresf referenced this pull request Jun 13, 2016
Closed

essentials things! #2843

@Umcaruje
Member
Umcaruje commented Jul 5, 2016

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

@michaelgregorius
Contributor

@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 Umcaruje removed the in progress label Jul 10, 2016
@Umcaruje
Member

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

Tested this out, code looks good, merging 👍

@Umcaruje Umcaruje merged commit 52ec387 into LMMS:master Jul 10, 2016

1 check passed

continuous-integration/travis-ci/pr The Travis CI build passed
Details
@michaelgregorius michaelgregorius deleted the michaelgregorius:fader-dbfs branch Jul 10, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment