Mixing question........levels

[selig]

I understand that the red in the channels is a decoration, that they should remove that red then

It does seem from a human interface design perspective that channel meters should be a gradient from green at the bottom toward yellow at the top. I'm sure RS is listening carefully to this thread and will rectify this in R12.

I've told them on multiple occasions that they could solve many misunderstandings by changing the channel's red LEDS to yellow, JUST LIKE WITH THE SEQUENCER METERS (sorry for yelling, hoping someone in Sweden will hear me).
There are many inconsistencies in the Reason UI, the difference between the sequencer audio meters (peak reading, yellow above -12 dBFS) and the channel meters (VU/RMS reading, red above -12 dBFS) being just one.

[sdst]

Lol. I think all DAW have that red clip, if that's not clipping then it's a confusing thing

[integerpoet]

You can't clip "everywhere" - in fact there is only one place you CAN clip - the final output.

For myriad excellent reasons, I will not dispute that.

I wonder, though, whether those floating point samples rattling around inside Reason will tolerate a finite amount of abuse before starting to degrade in other ways. If they're fed through an effects chain which inflicts a series of extreme amplifications and attenuations on them, the signal at the end can't be perfectly identical, can it?

I suppose one might never encounter an issue in practice because when a quiet signal passes through a non-trivial effect which amplifies the signal significantly, the output is largely "created" by the effect anyway. So to demo such a degradation clearly I guess you'd have to set up a weird pathological chain which only amplifies and attenuates.

Am I making any sense at all here?

[integerpoet]

It does seem from a human interface design perspective that channel meters should be a gradient from green at the bottom toward yellow at the top. I'm sure RS is listening carefully to this thread and will rectify this in R12.

I've told them on multiple occasions that they could solve many misunderstandings by changing the channel's red LEDS to yellow, JUST LIKE WITH THE SEQUENCER METERS (sorry for yelling, hoping someone in Sweden will hear me).
There are many inconsistencies in the Reason UI, the difference between the sequencer audio meters (peak reading, yellow above -12 dBFS) and the channel meters (VU/RMS reading, red above -12 dBFS) being just one.

I recently saw Ryan's video about gain-staging (or more accurately the lack of a need for it) posted on Facebook and wondered aloud if there would have been any need for such a video were it not for the red used in channel meters.

In a prior chapter of my career, I actually implemented meters with a smooth gradient between green and yellow with a single red segment at the top for clipping (needed because this was software for a hardware input), and there were a lot of questions about it. It seems there is unconscious/informal/cultural inertia behind having multiple red segments, some of which may light up for a signal which isn't actually clipping. I don't know where the inertia comes from, but I suppose it's possible that for monitoring input you may want multiple red segments because unless you have hardware smart enough to report actual clipping then any sufficiently hot signal may pose a risk of having clipped too quickly to detect. In such a situation the multiple red segments could mean "risk of clipping" rather than "you clipped" and "risk of clipping" is deemed bad enough to use red. But then the debate just shifts to what value should be considered "sufficiently hot", so I'm still thinking for my own use I'd rather see a gradient from green to yellow.

[EdGrip]

The minute you start using plugins that are analog modeled or do anything non-linear (like saturation type plugins), you absolutely do have to worry about the signal levels going into those plugins, which means paying attention to the levels of other things in the chain. Emulations of hardware (like the 1176, LA-2A, LA-3A, etc) mimic the distortion that occurs at certain levels, so you need to reference similar levels in the box, or else you will get VERY audible aliasing distortion (unless you run your audio at 96kHz or higher, and/or have plugins that oversample/allow oversampling).

This is such a good video at explaining lots of stuff, including how higher sample doesn't "improve" the resolution of sounds across the frequency range in the way you might expect - a concept first explained to me by Selig, on here. Dan Worrall is an excellent communicator and his tutorial videos for TDR plugins and U-He Repro are an education.

But, this video is all about sample rate. This thread is really about bit depth, the way bit depth is handled in floating point DAWs, and when/if gain staging is important in systems like that. So my understanding is, while non-linear plugins will (by definition and by design) behave differently depending on the input level - that's why you use them - aliasing isn't caused by poor gain staging in itself.

That is, if you've added a plugin which is compressing and/or saturating by (X) amount, presumably you're doing that on purpose, even if it's adding aliasing or making it louder.

[Kalm]

I just simply make sure my channels don't clip.

Channels CAN'T clip - only the final output to your D/A (or file export) can clip.

mixbus. . . . same shimo

[selig]

I recently saw Ryan's video about gain-staging (or more accurately the lack of a need for it) posted on Facebook and wondered aloud if there would have been any need for such a video were it not for the red used in channel meters.

In a prior chapter of my career, I actually implemented meters with a smooth gradient between green and yellow with a single red segment at the top for clipping (needed because this was software for a hardware input), and there were a lot of questions about it. It seems there is unconscious/informal/cultural inertia behind having multiple red segments, some of which may light up for a signal which isn't actually clipping. I don't know where the inertia comes from, but I suppose it's possible that for monitoring input you may want multiple red segments because unless you have hardware smart enough to report actual clipping then any sufficiently hot signal may pose a risk of having clipped too quickly to detect. In such a situation the multiple red segments could mean "risk of clipping" rather than "you clipped" and "risk of clipping" is deemed bad enough to use red. But then the debate just shifts to what value should be considered "sufficiently hot", so I'm still thinking for my own use I'd rather see a gradient from green to yellow.

The most recent time I requested getting rid of the red LEDS was when Ryan consulted me for that very video!
As for colors, let’s start with the fact channels can’t clip so don’t need clip indicators. Secondly, clipping isn’t straight forward to define at every stage since values above 0 dBFS don’t exist in fixed point audio. So clipping is often described as 3 or 4 samples at 100%, since you don’t have samples above 100%.
Finally, a smooth gradient may make more sense in analog where signals gradually overload. In digital you’re fine right up to 100%, so the “Stop Light” analogy makes more sense: green for “go”, yellow for “get ready to stop”, and red for “stop”. Also, it’s handy to have indication of certain ranges, which is what I did for Selig Gain using red ONLY for 0 dB and above, yellow for -12 to 0 dBFS, green for -24 to -12 dBFS, and blue for levels below-24 dBFS.

[integerpoet]

As for colors, let’s start with the fact channels can’t clip so don’t need clip indicators. Secondly, clipping isn’t straight forward to define at every stage since values above 0 dBFS don’t exist in fixed point audio. So clipping is often described as 3 or 4 samples at 100%, since you don’t have samples above 100%.
Finally, a smooth gradient may make more sense in analog where signals gradually overload. In digital you’re fine right up to 100%, so the “Stop Light” analogy makes more sense: green for “go”, yellow for “get ready to stop”, and red for “stop”. Also, it’s handy to have indication of certain ranges, which is what I did for Selig Gain using red ONLY for 0 dB and above, yellow for -12 to 0 dBFS, green for -24 to -12 dBFS, and blue for levels below-24 dBFS.

That's kinda what I was getting at. Software displaying hardware input levels is in a gray area where the data is (obviously) digital but has come from a device with analog circuits which the user cares about. I suppose it might be cheaper for audio hardware to implement a digital heuristic for clipping rather than report actual clipping, but I want to believe the hardware in my story was not that cheap because the price-point certainly was not!

Meanwhile, I imagine an app accepting input from an audio API is in a weirder position because it knows analog hardware might be involved, but due to API abstraction the app knows less about that hardware; details like a discrete clipping bit may not survive up through the software stack and into the app even though the user still cares about clipping — or should, anyway.

Without some RS insider with a long memory showing up here to tell the tale, I guess we'll only be able to speculate, but I wonder if that kind of problem is what led to so many red segments in the channel meters. I'm not saying it's the best solution, but perhaps it was deemed safer during recording — ahem; Record-ing — than the 3-or-4-samples-at-100% heuristic. But of course I might be trying too hard to cut them slack.

[selig]

.
Without some RS insider with a long memory showing up here to tell the tale, I guess we'll only be able to speculate, but I wonder if that kind of problem is what led to so many red segments in the channel meters. I'm not saying it's the best solution, but perhaps it was deemed safer during recording — ahem; Record-ing — than the 3-or-4-samples-at-100% heuristic. But of course I might be trying too hard to cut them slack.

The meters in question are not involved in the recording stage - the meters for recording audio are different: peak rather than VU, yellow rather than red LEDS for the top 12 dB. Those meters work great for me, it’s the channel meter that make no sense: VU and red LEDs for the top 12 dB.
Really not sure why they are different, even more unsure why they can’t be changed or aren’t changed when you change the Master/Big meters...

[Desnuda]

A real world example would be trying to get out of a speeding ticket by arguing your AVERAGE speed was well under the speed limit... click test

[guitfnky]

A real world example would be trying to get out of a speeding ticket by arguing your AVERAGE speed was well under the speed limit...

why did you just repost Selig’s comment without even quoting him?