db/VU Type Meter to Overlay Fader?

Poppadocrock

Good points @wim I like it lean and clean, lol.

Strigoi

@j_liljedahl said:

Yes. Knowing the numerical peak value is usefull because it shows you how many dB you need to lower the gain to keep it below 0 dB, or how much peak headroom you have left. I'm not sure a numerical display of RMS is useful in general. But if one needs advanced metering, one probably will want to use some metering plugin with fancy inter-sample peak detection, and LUFS, etc.

Is there any reason why the main meter can’t be ebu r128 with ISP detection, instead of RMS? There’s even room for a momentary/short term toggle on the side. R128 is an open standard, with code available, so I don’t think it would take long to implement it.

Vmusic

@j_liljedahl

One more time..... my suggestion was to allow the channel meters to be:

• hidden or shown (user's choice) ~~~> it does NOT have to take up more real estate, unless the users want to see it
• in fact, you likely can show or vertically stack the IN /OUT meters (see screen snapshot)
• i myself - absolutely LOVE the idea of allowing this channel IN/OUT metering to be switched to apply to one specific plugin in the channel; this would be great for troubleshooting (see screen snapshot)

remember
.... some users are instrument players using AUM like a pedalboard or multi-fx processor; this channel signal metering (and specific plugin metering) feature is not available in my Helix. It wasn't available in my $2,000 Axe Fx either.

and now..... you're considering creating an entirely NEW WINDOW or view? is it really needed? Look at the vastly improved screen snapshot here ::: my last comment, I promise.
Thank You

@j_liljedahl said:

@wim said:
I personally like the lack of big meters for each channel. I want AUM lean and non-distracting. Multiple big meters come at the cost of CPU. They distract me from using my ears for leveling. They encourage a largely not needed emphasis on gain staging harking back to when analogue equipment clipped at anything above 0db.

DAWs today don't clip internally at 0db. Plugins may, so it's important to watch those, but that's within a channel's signal path and needs to be monitored there. A big-ass channel fader isn't going to tell you anything about the level going into and out of a distortion plugin, for instance.

AUM gives me all the metering I want or need, without distracting me while creating. It's immediately obvious when I'm sending potentially too much, and it's not that difficult to track back to where I might want to do some gain staging to avoid build-up of problems. Unless I'm getting clipping on the master I really don't give a crap about the rest except input to individual plugins that are gain sensitive. I don't care about RMS either except at the final mix down. I certainly don't want to be thinking about it while fine-tuning a mix by ear.

I guess it's comforting to people to have that visual representation front and center. Or maybe we're all just used to it from DAWs modeled to look like their analog ancestors. To me it serves no purpose. But I'm arguing uselessly here as I've never once seen anyone change their mind on this topic. So I'll shut up now.

I will say that I hope if there were ever to be something like this in AUM that it would be in the form of a built-in windowless plugin that could be added if and where desired, not an integrated part of the UI.

Thanks, I fully agree. The simple 3 dot meters do tell you all that's needed IMHO.

I will consider making a separate full screen meter bridge view, but I have the feeling most users would prefer I prioritize other common requests such as Receive MIDI Clock

NeonSilicon

@Vmusic said:
@j_liljedahl

One more time..... my suggestion was to allow the channel meters to be:

• hidden or shown (user's choice) ~~~> it does NOT have to take up more real estate, unless the users want to see it
• in fact, you likely can show or vertically stack the IN /OUT meters (see screen snapshot)
• i myself - absolutely LOVE the idea of allowing this channel IN/OUT metering to be switched to apply to one specific plugin in the channel; this would be great for troubleshooting (see screen snapshot)

remember
.... some users are instrument players using AUM like a pedalboard or multi-fx processor; this channel signal metering (and specific plugin metering) feature is not available in my Helix. It wasn't available in my $2,000 Axe Fx either.

and now..... you're considering creating an entirely NEW WINDOW or view? is it really needed? Look at the vastly improved screen snapshot here ::: my last comment, I promise.
Thank You

@j_liljedahl said:

@wim said:
I personally like the lack of big meters for each channel. I want AUM lean and non-distracting. Multiple big meters come at the cost of CPU. They distract me from using my ears for leveling. They encourage a largely not needed emphasis on gain staging harking back to when analogue equipment clipped at anything above 0db.

DAWs today don't clip internally at 0db. Plugins may, so it's important to watch those, but that's within a channel's signal path and needs to be monitored there. A big-ass channel fader isn't going to tell you anything about the level going into and out of a distortion plugin, for instance.

AUM gives me all the metering I want or need, without distracting me while creating. It's immediately obvious when I'm sending potentially too much, and it's not that difficult to track back to where I might want to do some gain staging to avoid build-up of problems. Unless I'm getting clipping on the master I really don't give a crap about the rest except input to individual plugins that are gain sensitive. I don't care about RMS either except at the final mix down. I certainly don't want to be thinking about it while fine-tuning a mix by ear.

I guess it's comforting to people to have that visual representation front and center. Or maybe we're all just used to it from DAWs modeled to look like their analog ancestors. To me it serves no purpose. But I'm arguing uselessly here as I've never once seen anyone change their mind on this topic. So I'll shut up now.

I will say that I hope if there were ever to be something like this in AUM that it would be in the form of a built-in windowless plugin that could be added if and where desired, not an integrated part of the UI.

Thanks, I fully agree. The simple 3 dot meters do tell you all that's needed IMHO.

I will consider making a separate full screen meter bridge view, but I have the feeling most users would prefer I prioritize other common requests such as Receive MIDI Clock

Now you need to try and get that UI on an iPhone display. Or, even an iPad Mini in landscape. From the data I have from my own AUv3's, iPhone users outnumber iPad users 2 to 1. That might not be true for AUM, but it's important to take that in to consideration.

The use cases for AUM are pretty broad and cover every iDevice configuration. Even a change like the show hide meter button is going to take space that lots of users don't want to give up. Checkout some of the videos where people have stacks of channels and busses setup in AUM. Making those users scroll even a little bit more is going to make them grumpy.

rs2000

What matters most to me is the relation between distortion and VU readout.
I'm OK with 3 LEDs and since I guess that the AUM internal bit resolution is high enough (@j_liljedahl: 32bit? float?), my rule of thumb would be to keep the yellow LEDs rarely flashing in my channels. Done.

wim

I dunno. I still feel like if I'm staring down a VU meter while I'm playing my instrument I'm doin' it wrong. A quick couple of real hard strums on the guitar to check the input levels to the signal chain and then I sure hope I don't need a meter to tell me how hard or soft to play. Ditto for when I used to play violin. I just don't understand what a fancy meter accomplishes while playing.

But, that's just me, I guess.

j_liljedahl

@Strigoi said:

@j_liljedahl said:

Yes. Knowing the numerical peak value is usefull because it shows you how many dB you need to lower the gain to keep it below 0 dB, or how much peak headroom you have left. I'm not sure a numerical display of RMS is useful in general. But if one needs advanced metering, one probably will want to use some metering plugin with fancy inter-sample peak detection, and LUFS, etc.

Is there any reason why the main meter can’t be ebu r128 with ISP detection, instead of RMS? There’s even room for a momentary/short term toggle on the side. R128 is an open standard, with code available, so I don’t think it would take long to implement it.

One reason is time and priorities, another is I think RMS and Peak levels are what users are used to see. ISP would be useful for Peak level but would add CPU consumption (oversampling needed), and again priorities..

j_liljedahl

@rs2000 said:
What matters most to me is the relation between distortion and VU readout.
I'm OK with 3 LEDs and since I guess that the AUM internal bit resolution is high enough (@j_liljedahl: 32bit? float?), my rule of thumb would be to keep the yellow LEDs rarely flashing in my channels. Done.

Yes, 32 bit float, so there's no internal clipping. The only places you need to be aware of your levels is at the point of recording (unless recording to float32 format) and when signal passes through nodes with non-linear behaviour.

Samu

One 'thing' that could be handy to avoid 'blowing my ears of accidents' would be if there was an adjustable brick-wall limiter as standard on the 'master output'(I know it would add a bit of latency but for protecting my ears it's something I can live with).

Sure I can always create an extra bus and slap a limiter on it and route the other tracks to it.

Some iOS synths just have way, way too hot output so I've had to reduce the default track level to -12 to avoid blowing everything off when I add new synths into the mix especially when the presets can go past 0dbFS when playing more than a few notes.

Adding too many 'basic' things to a track makes the up/down swiping a bit boring.
There must be a better way to use the screen than the circles?
('value-boxes' that can be swiped up/down or left/right to adjust and long-tap value entry/parameter-change?).

Even the fader could be a swipe-able value-box as the 'precision' would remain the same, it's after all a touch-screen no need to have 'moving objects'.

Sorry for letting off some brain-farts...
Cheers!

j_liljedahl

@Vmusic said:
@j_liljedahl

One more time..... my suggestion was to allow the channel meters to be:

• hidden or shown (user's choice) ~~~> it does NOT have to take up more real estate, unless the users want to see it
• in fact, you likely can show or vertically stack the IN /OUT meters (see screen snapshot)
• i myself - absolutely LOVE the idea of allowing this channel IN/OUT metering to be switched to apply to one specific plugin in the channel; this would be great for troubleshooting (see screen snapshot)

remember
.... some users are instrument players using AUM like a pedalboard or multi-fx processor; this channel signal metering (and specific plugin metering) feature is not available in my Helix. It wasn't available in my $2,000 Axe Fx either.

and now..... you're considering creating an entirely NEW WINDOW or view? is it really needed? Look at the vastly improved screen snapshot here ::: my last comment, I promise.
Thank You

I won't do that kind of large re-design of the UI for something that I don't even think is needed, sorry

However, I'll consider adding a way to temporarily meter the in/out levels of a node. It could be an item in the new node long-press menu.

Strigoi

@j_liljedahl I found a library implementation of EBU R128, I don't know if you are aware of it: https://github.com/jiixyj/libebur128 Maybe it makes everything easy and fast?

The ISP detection is part of the standard, but in a technical sense it has nothing to do with the metering. You could skip it. Same thing with the integrated loudness. I don't see how it would be of any use in AUM, and it would only confuse people. A simple ML/ST toggle near the meter would be much cleaner and intuitive.

Since this thread started with VU, I should mention something, for anyone that might not know this: the "momentary" setting of a EBU R128 meter is meant as a modern replacement of VU (invented in 1940). It's better in every way, but also should feel very familiar to anyone that has worked with VU.

j_liljedahl

@Strigoi said:
@j_liljedahl I found a library implementation of EBU R128, I don't know if you are aware of it: https://github.com/jiixyj/libebur128 Maybe it makes everything easy and fast?

The ISP detection is part of the standard, but in a technical sense it has nothing to do with the metering. You could skip it. Same thing with the integrated loudness. I don't see how it would be of any use in AUM, and it would only confuse people. A simple ML/ST toggle near the meter would be much cleaner and intuitive.

Since this thread started with VU, I should mention something, for anyone that might not know this: the "momentary" setting of a EBU R128 meter is meant as a modern replacement of VU (invented in 1940). It's better in every way, but also should feel very familiar to anyone that has worked with VU.

Thanks, I'll have a look.

Vmusic

I believe the foundational request or concept here is to be able to

• OPTIONALLY measure the loudness of the signal path through the entire channel (at the final output of the channel)
• OPTIONALLY measure the loudness of the signal path through an fx/plugin node (at the output of the fx/plugin node)

The exact unit of measure or mechanism was only for reference. The idea was never what should be the ideal units or measurement. I work a lot with Cubase, and I'm familiar their displays; but others are fine.

It "seems" if you're taking the effort to write code that
1. measures or monitors the loudness (at any point in the signal chain)
2. then display the loudness (of what is measured in step 1)

THEN..... some of the work is done for both requests. It's just a matter of letting the user dictate where in the signal chain or at what point in the signal chain; either the output of particular fx/plugin node - or - the output of the channel itself. Maybe it's not true; but it seems like "measuring the loudness and displaying the loudness" is the same or nearly the same no matter where in the signal path it's measured. FOR CERTAIN - the display should be the same.

Thanks!!!

musikeer

When Prince’s meters went into the red, he put track sheets over them so he couldn’t see them.

Vmusic

Are you sure? I thought he had the software rewritten so the dB meter went to Purple.

@musikeer said:
When Prince’s meters went into the red, he put track sheets over them so he couldn’t see them.

wim

@Vmusic said:
I believe the foundational request or concept here is to be able to

• OPTIONALLY measure the loudness of the signal path through the entire channel (at the final output of the channel)
• OPTIONALLY measure the loudness of the signal path through an fx/plugin node (at the output of the fx/plugin node)

The exact unit of measure or mechanism was only for reference. The idea was never what should be the ideal units or measurement. I work a lot with Cubase, and I'm familiar their displays; but others are fine.

It "seems" if you're taking the effort to write code that
1. measures or monitors the loudness (at any point in the signal chain)
2. then display the loudness (of what is measured in step 1)

THEN..... some of the work is done for both requests. It's just a matter of letting the user dictate where in the signal chain or at what point in the signal chain; either the output of particular fx/plugin node - or - the output of the channel itself. Maybe it's not true; but it seems like "measuring the loudness and displaying the loudness" is the same or nearly the same no matter where in the signal path it's measured. FOR CERTAIN - the display should be the same.

Thanks!!!

Sorry if this sounds pedantic, but do you mean "loudness", or peak signal level? Those are very different things.

Loudness is perceived volume and involves more than just peak signal levels. Two tracks with the same maximum peak levels can have very different perceived loudness due to compression and other factors. LUFS is the most common loudness measurement standard these days, in use by most steaming platforms. It requires measurement over time that's impractical for live level metering.

RMS and peak are the most common ways of measuring signal level. RMS uses average signal level over short periods of time. Peak is an instantaneous measure.

Sorry technophiles if I've over generalized. I'm trying not to get bogged down in technical details.

Strigoi

@wim said:

LUFS is the most common loudness measurement standard these days, in use by most steaming platforms. It requires measurement over time that's impractical for live level metering.

RMS and peak are the most common ways of measuring signal level. RMS uses average signal level over short periods of time. Peak is an instantaneous measure.

Loudness can be measured on any time frame. Streaming services use integrated loudness, meaning the loudness of an entire track. EBU R128 also defines two other time frames:

• momentary, with a time frame of 400 ms, meant to replace old analog Voltage Units based metering
• short term, with 3 seconds time frame, which is easier to read than momentary, for general purposes

Both of these are aimed at live level metering.

Internally, the EBU R128 standard DOES use RMS. But it also uses weighting of frequencies, to better represent how human hearing works, and standardised time frames. Root mean square (RMS) is just math without a context.

wim

Thanks @Strigoi. Good info.

NeonSilicon

@Strigoi said:

@wim said:

LUFS is the most common loudness measurement standard these days, in use by most steaming platforms. It requires measurement over time that's impractical for live level metering.

RMS and peak are the most common ways of measuring signal level. RMS uses average signal level over short periods of time. Peak is an instantaneous measure.

Loudness can be measured on any time frame. Streaming services use integrated loudness, meaning the loudness of an entire track. EBU R128 also defines two other time frames:

• momentary, with a time frame of 400 ms, meant to replace old analog Voltage Units based metering
• short term, with 3 seconds time frame, which is easier to read than momentary, for general purposes

Both of these are aimed at live level metering.

Internally, the EBU R128 standard DOES use RMS. But it also uses weighting of frequencies, to better represent how human hearing works, and standardised time frames. Root mean square (RMS) is just math without a context.

RMS isn't math without context. It has a definite meaning. It may not be the meaning you are looking for, but that's a different question.

My take on the original request in this thread would be that a 3 sec delay would be too long. If I'm going to try and use a level measure to trip a clamp on the output volume for speaker and ear protection, then 400ms is too long. Maybe for the requested usage 400ms would be OK. It all depends on what and why.

j_liljedahl

@Vmusic said:
I believe the foundational request or concept here is to be able to

• OPTIONALLY measure the loudness of the signal path through the entire channel (at the final output of the channel)
• OPTIONALLY measure the loudness of the signal path through an fx/plugin node (at the output of the fx/plugin node)

AUM already allows you to measure the levels (peak and RMS) at the final output of any channel. Just tap the 3 dots next to the channel output node to bring it up in the main level meter.

The second request is something I'm considering adding, a way to show input/output meters of a specific node for trouble-shooting etc. It could also display the DSP% and latency etc for that specific node.

NeonSilicon

I haven't really paid much attention to LUFS up to now because I don't have any use for measuring things that way since I'm not doing any mastering for release or broadcast TV. After this conversation here, I went and grabbed the spec. Here's a couple of links to the broadcasting reqs and the LUFS spec.

https://tech.ebu.ch/docs/r/r128.pdf
https://www.itu.int/dms_pubrec/itu-r/rec/bs/R-REC-BS.1770-0-200607-S!!PDF-E.pdf

The spec is an interesting read. The first thing is that this is an easy algorithm, so if anyone wants to program it, there's no need for an external library. The spec lays out well what it's designed to do and from that a good idea of where using it would be appropriate. There's also an interesting annex to the doc Guidelines for accurate measurement of “true-peak” level that describes the issues with inter-sample peaking and measuring peak levels. Since this has implications for other things like chains of plugins that use upsampling, it's also pretty useful to understand in a wider context.