How Reason's coarse knobs & sliders work?

[antic604]

One characteristic thing about Reason is that its knobs & faders don't move by smallest possible increments, but in steps which often aren't equal.

How is this done?

Is there a table for each device and each control that lists consecutive steps for normal and for precise (when Shift is pressed) movements? Or a math function that discretises the range?

Sorry, was always fascinated by this design choice

[Loque]

Wait...i just hack into the server and copy the source code...

[selig]

For some devices, the parameter moves even when the tool tip value doesn't (when using Shift). This can happen because many knobs only have 63 frames in the visual 'animation', but at LEAST 127 values at the parameter.
This also happens for controls that have 1000 values, such as many of the SSL mixer controls (faders and EQ frequencies for example).
There are also floating point controls, I recently gave an example of how Selig Gain can have levels set down to 0.000001dB resolution by automating the fader and typing in the value. Many other REs do the same, but you have to figure it out for yourself by trying the "edit trick".

So while the edit parameter is equal steps (127 or 1000 total) the parameters they control are not always going to move in equal amount (boo). For example, for the SSL faders every step is a different decibel amount. This is why you can't scale automation in Reason accurately, as it changes the relationship between values. For example, a 3dB automation change won't be 3dB if you drag all the automation points up/down, a major deal breaker for mix automation IMO.

Basically each decibel is around 1 more "1-000" step apart the higher you go. At the top (+8dB) you have around 36 steps per decibel (it's not exact), and even just down at -10dB you have only 20 steps.
While the resolution is still nice and high, way more than you need regularly (1/20th of a dB), it's not consistent. So if you scale an automation move down by a few dB, you have changed the decibel relationship between the points - literally no other DAW I've ever seen does this.
For reverence, here's a chart I made years ago for converting values from 0-127 (14:2 mixer, etc) to the SSL 0-1000.

[antic604]

For some devices...

Awesome, thanks!

[aeox]

the parameter moves even when the tool tip value doesn't

I noticed this by chance and ever since then, I learned to stop looking at numbers

[antic604]

the parameter moves even when the tool tip value doesn't

I noticed this by chance and ever since then, I learned to stop looking at numbers

Yup. That's one of the things I really like in Reason. In other DAWs I seem to obsess about the "values" (compounded by my mild OCD, which only "accepts" specific values, e.g. 0.5dB, 1dB, 1.5dB, 3dB, 6dB, etc... ), but in Reason I often just look away and listen to the sound, while Shift-adjusting the parameter. Love it!

[selig]

I noticed this by chance and ever since then, I learned to stop looking at numbers

Yup. That's one of the things I really like in Reason. In other DAWs I seem to obsess about the "values" (compounded by my mild OCD, which only "accepts" specific values, e.g. 0.5dB, 1dB, 1.5dB, 3dB, 6dB, etc... ), but in Reason I often just look away and listen to the sound, while Shift-adjusting the parameter. Love it!

Years ago (late 1990s) as DAWs were already everywhere and I was already mixing ITB, I spoke with a Nashville mastering engineer casually on a break. We had both embraced working ITB, and we were comparing notes. At one point he stopped and looked at me and said “I DO have one problem working this way”. He “admitted” not liking seeing odd values such as 2.1 or 4.3 and would type in “2” and “4” without thinking. I admitted doing the same thing, and we both were not happy about it.

Even at the highest levels I’ve run into folks who seem affected by this. Dan Worrell (sp?) even mentions “hating himself” for making things look good on screen without even thinking about it. The visual sense is SO dominating it is a difficult thing to overcome, even when you KNOW you’re doing it.

I’m sure I’ve done twice the work needed, once to get the sound, and a second adjustment to get the “visuals” whether it be smoothing an EQ graph or typing in integers to avoid decimals.

But the good news is, that is difficult to do in Reason, especially since you can’t type in values (except for if you automate a control and use the sequencer Edit Mode). That’s also why I rarely open the Spectrum Window when using EQ.

That way I have 100% of my focus on sound rather than splitting my attention between how it sounds and how it looks. The struggle IS real, and I deal with it every day.

[antic604]

...That’s also why I rarely open the Spectrum Window when using EQ.

This. I need to do this one more (or less) often, too!

[Mikasa23]

Reason's knobs and faders move in steps, not tiny increments. A quantization function rounds user input to the nearest available step value. Step size depends on the parameter,wordle unlimited user interaction, and doesn't rely on pre-defined tables.

[selig]

Reason's knobs and faders move in steps, not tiny increments. A quantization function rounds user input to the nearest available step value. Step size depends on the parameter,wordle unlimited user interaction, and doesn't rely on pre-defined tables.

Not unless you specify it in the code. As I've pointed out, on Selig Gain, you can type in 6 decimal points of precision on the knob if automating it. There are other REs that do the same. You CAN quantize knobs, such as I did with ColoringEq to get semitone steps for frequency on the EQ/Filter bands. You could also specify decibel steps as I did with Infuser, you don't need to leave it full floating point resolution.

There is also the stepped vs smooth behavior you can choose from. Stepped is used in Infuser for tuning and you can see it when you automate a control and cannot draw diagonal lines with interpolated values. Compare to Decibels in Infuser, where the steps are quantized but you can still have diagonal lines between values. One if for cases where you don't want to slide between values when automating such as pitch/frequency controls, the other is for when you want quantized values but DO want to slide between steps in the sequencer.

In the image below, both examples are automating a control in Infuser, both are quantized (the top in semitones, but bottom in decibels) so you can only enter steps "on the grid". But the difference is one allows interpolation between values (the second example) and that in tern allows curves in the segments as shown.

Screen Shot 2024-02-29 at 8.31.31 AM.png

All to say, the examples given DO rely on pre defined tables, the note names for the tuning control were entered into the code ourselves (we created the "table") and this is pretty common.