default gain setting is different between mix channel faders and volume knobs?

[RandyEspoda]

Hi,

I've just been changing over some older reason projects that were made prior to the SSL mixer and convert them onto mixer channels.

But I've bumped into a weird instance that I never really noticed, where the default gain level of the 0-127 volume knobs is "not" the same as the default 0db level on the mix channel faders.

On the mixer faders, unity level or 0db is set at 734 increments out of 1000 max increments.
But on a 0-127 volume knob, default gain (which i always assumed was 0db) is set at 100 increments out of 127 max increments.

When calculating these figures, a weird thing comes up, namely that the default "100" on the 0-127 knobs is NOT the same level as the "734" gain setting on the mix faders. So logically, one of the two is NOT set at 0db unity gain.

This kinda blows my mind. When I have a 14:2 mixer set at "100", assuming it is 0db, then calculating the correct increment value on the mix fader for the same level of gain becomes 787 instead of 734, putting it at 1;82db instead of 0db.

Because when considering 127 max level conforming to the max level of "1000" increments (= +8.06db) on a mixer channel fader, then level 100 on the knob becomes level 787 (=1.82db) on the mix channel fader.

127=1000
1 = 1000/127 = 7.874
100 = 7.874 x 100 = 787



In other words, level 100 on the 0-127 volume knobs would then be a level of 1.82db instead of 0db...
Again, this blows my mind, because one would "think" the default gain setting of 100 would be chosen at 0db...

Perhaps I'm an idiot and completely miscomprehending this, but I rather doubt that is the case...

All gain automation settings of 100, when converted onto mixer channels, then convert it to "787" increments on the mixer channel fader, which conforms to 1.82db...

At the cost of repeating myself, it blows my mind and it kinda s**cks when trying to convert older project racks to mixer channels...


Any info on this would be much appreciated, as I am fairly sure that this subject had already been discussed before and overcome by many.

[Pepin]

The controls don't cover exactly the same range, and it's not straightforward to convert between them. The maximum setting on the SSL is louder for instance.
But 100 on the 14:2 is the same as 734 on the SSL. That's the one thing you can be sure of.

[selig]

The faders have different "tapers", so they don't line up as you expected.
Here's how to convert from one to the other (and yes, 100 is unity/0dB):

[selig]

Oh, I forgot to add that if you are wondering if 100 is 0 dB or not, test it.
Play a single oscillator patch with no modulation at all, like the default (reset) Thor patch. Check the level, and then add a Line or 14:2 Mixer. The signal level will not change, correct? This means the mixer is unity because it's not adding or subtracting level.

[RandyEspoda]

Aha...

I did test it with an oscilloscope like you suggested and indeed. 0db...

That chart is awesome, exactly what I needed. Many thanks!

But then the built-in conversion (= adjust alien clips ...) does not calculate correctly from 100 to 734 on the mix faders...
I tried that and it gives the same calculation I used in the first post. It converts 100 to 787 on the mix faders...

It's a hassle, but with that chart I'll manage just fine. Thank you Selig!

[selig]

OK, one more thing worth mentioning regarding how gain automation is handled with the faders in Reason.
Since the faders use an arbitrary 0-1000 range and it’s not linear with regards to decibels, adjusting multiple automation points skews the relative gain points. Meaning, if you have automation that moves up 6 dB at one point, then back down 6 dB later, and then you select all these points and raise or lower them together, the distance between the high and low point will no longer be 6 dB!
This is an example (for those who ask) of how Reason is not up to professional standards, because we would expect gain relationships to remain intact when adjusting multiple automation points at once.
So not only is it impossible to see decibel values when automating/editing fader automation data, you cannot accurately scale it either.
This is one of the many limitations I sought to address with Selig Gain, and when I first released it I had assumed it would quickly become redundant as these issues were addressed by RS. So far none of them have been addressed, so much to my surprise Selig Gain remains a useful device in Reason (IMO!).

For example: 0 dB = 734, -6 dB = 583, and -12 dB = 463. The first -6 dB requires a change of 151, but the second -6 dB requires a change of 120. Bottom line, each change of 1 dB on the fader requires a DIFFERENT amount of change with the automation data. Saying it the other way around: each change of 1 unit of automation data results in a DIFFERENT amount of decibel change.

That said, I still automate with the faders in Reason, I just can’t do much more than the basics there. Conversely, in other DAWs (I’m using LUNA these days), you just put the fader in trim mode and move it up or down and all the recorded automation data will scale (offset, technically) accurately. You can also select the automation points and raise/lower them while seeing the decibel value.

And it’s confusing to me why it was done this way because it is super easy to have fader values read AND automate in decibels as I have done in Selig Gain (and just about every other developer including RS has done with their level/volume controls that read in decibels from Processed Pianos to Algoritm, A-List Guitars to Friction, and so on). Or at the least they could have created a linear scale/mapping for the 0-1000 to dB range so that Trimming automation values would be correctly executed.
Whew, good to get that out of my system!

Side note - grouping faders DOES work properly in that decibel relationships are properly maintained when multiple faders are moved ‘as one’.