Hey, exact values for mixer?

[fungames]

I am using shift while moving the fader in the mixer, but it still snaps to like .23 .55, Without typing the custom value how am I supposed to move it exactly .01?

If this is not possible, is there a controller that will let me have more precision?

[jam-s]

It's no use fiddling with .01 increments for the mixer faders as 0.2 dB volume difference is less than most peaople can reliably hear anyway. And in full mix its even less noticeable. But if you OCD compells you to have exactly -6.00 dB instead of -5.82 dB or something, then you have to create an automatin lane for the fader and then type in the value closest to the one that gives you -6.00 dB.

[fungames]

Well, I was hearing an actual difference when I was mixing, thank you though.

[selig]

The mixer fader is really odd in the way it functions. There are basically 1000 possible automation/fader steps, divided unevenly across the total range. So this means a few things.

For one, it means you cannot type a value in decibels, but rather you must use the 0-1000 scale. To make matters worse, the relationship between the 0-1000 values and decibels is totally non linear. Meaning for example that 1 dB is a different value at every possible level. For example, the difference between 0dB and -1dBFS (1dB apart) is 28 steps (in the 0-1000 scale). But the difference between -10 and -11dBFS (also 1dB apart) is just 19. And it's different for every step in the dB scale, which brings us to our next issue.

If you select multiple fader automation points and drag them all up or down, as you may often want to do (to make the entire first verse vocal 1dB hotter, for example), you will loose your level relationships in your automation. Meaning for example, a 1dB change will no longer be a 1dB change, a 4.5dB change will no longer be 4.5dB. And it will be different when you raise levels as when you lower them. In every other DAW I've ever hear of, if you raise a selection of multiple fader automation points, their relative spacing will not change - a 6dB boost on the bridge will still be a 6dB boost, it will just start higher or lower than before you edited the automation points.

I don't get it, there's no reason NOT do allow this. I'm a first time audio software dev (selig Audio) and I managed to create a volume fader that automates in decibels up to 0.00001dB resolution (even though it only shows 1/10dB resolution in the automation lane).

[fungames]

Awesome, thanks, yea me either. Just they could make it so when you use scroll wheel while clicking and holding the fader, the scroll wheel it snaps to .01 or .1 or what ever increments.

Do you think you could program a midi CC changer for me? I want to use my multitimbral synth with reason :'/

There is no MSB, LSB in midi external instrument included with reason - only program. I've tried everything to send the correct CC with my FA06 PDF:
https://cf3.zzounds.com/media/FA-06_08_ ... 13d53f.pdf

I would prefer a patch list, but I am okay with using Midi CC sends. Ugh. Just have not found a working solution, My fa06 is unusable. It only lets me select 1-128 as GM. LOL. I thought about getting 16 FA06, but there does not seem to be a way to send proper Midi CC.

I am looking at CV extensions now, but I've not found a working method. It's so sad. .

[Pepin]

There are basically 1000 possible automation/fader steps, divided unevenly across the total range.

I'm pretty sure the steps evenly divide the fader position, so 500 has the fader at ~50%, 750 at ~75%, and so on. It will slightly off since there are 1001 steps total.

To be fair, this matches how nonlinear controls typically work in Reason. If you automate the filter cutoff on Europa, you'll see that the 50% automation value is 779.5 Hz, which matches the 50% knob position. It's not the halfway point of the numerical range for the property (which ranges from 37.6Hz to 16.7 kHz). As you probably know, RE developers have to provide transform and inverse transform functions for these types of nonlinear controls. The value saved on disk is typically the linear control position, which then has a transformation applied for display purposes (and calculations elsewhere).

The main issue with the SSL fader is that--unlike REs--this transformation is not applied when numerically displaying automation data in the sequencer.
This unfortunately is consistent with other pre-RE devices. If you automate the filter cutoff on Thor, the same thing happens. Turning the knob shows a nice Hz value, but automation just gives you an opaque value from 0 to 127 representing the knob position. The only difference is the SSL fader gives you a lot more than 128 steps to work with.

Ultimately, Reason was not great about this stuff in the pre-RE days, and none of the subsequent improvements have been backported to older devices (mixer included).

[Tiefflieger Rüdiger]

If you select multiple fader automation points and drag them all up or down, as you may often want to do (to make the entire first verse vocal 1dB hotter, for example), you will loose your level relationships in your automation.

That is really bad. I'm using the RRP so I'm not affected by this but this should get fixed. Did you ever report this to the devs?

[Pepin]

If you select multiple fader automation points and drag them all up or down, as you may often want to do (to make the entire first verse vocal 1dB hotter, for example), you will loose your level relationships in your automation.

That is really bad. I'm using the RRP so I'm not affected by this but this should get fixed. Did you ever report this to the devs?

All non-linear controls will exhibit this issue, because automation data evenly spans the range of the control (knob, fader, etc). There's no way to uniformly raise Europa's filter automation by 100Hz either, for instance. It's just less showstopping in that case, because meaningful values are displayed that can still be adjusted one at a time. At a minimum, that could be fixed for the SSL faders.

Though ideally, dragging multiple points in this scenario would adjust them at different rates. Other DAWs do this, and mixer faders are a special case where this is more important than elsewhere imo.

[fungames]

Yea, I do not have a problem with it, I am just OCD and it triggers it hard, especially when setting up a project template.

Dragging a slider and seeing -11.58db on one and -11.53db on another and having to switch my mouse sensitivity to 400dpi instead of 800dpi, just so I can hit the exact # kind of sucks. Also, snapping the main slider to -9db or -6db or -10db or what ever, never happens. It is just annoying more than anything.

[fungames]

Awesome, thanks, yea me either. Just they could make it so when you use scroll wheel while clicking and holding the fader, the scroll wheel it snaps to .01 or .1 or what ever increments.

Do you think you could program a midi CC changer for me? I want to use my multitimbral synth with reason :'/

There is no MSB, LSB in midi external instrument included with reason - only program. I've tried everything to send the correct CC with my FA06 PDF:
https://cf3.zzounds.com/media/FA-06_08_ ... 13d53f.pdf

I would prefer a patch list, but I am okay with using Midi CC sends. Ugh. Just have not found a working solution, My fa06 is unusable. It only lets me select 1-128 as GM. LOL. I thought about getting 16 FA06, but there does not seem to be a way to send proper Midi CC.

I am looking at CV extensions now, but I've not found a working method. It's so sad. .

viewtopic.php?p=677986#p677986

Took me soooo long. Not a fan of Reason 13 not having a patchlist. Hope 14 gets it during its dev stages.

[Tiefflieger Rüdiger]

That is really bad. I'm using the RRP so I'm not affected by this but this should get fixed. Did you ever report this to the devs?

All non-linear controls will exhibit this issue, because automation data evenly spans the range of the control (knob, fader, etc). [...]

Though ideally, dragging multiple points in this scenario would adjust them at different rates. Other DAWs do this, and mixer faders are a special case where this is more important than elsewhere imo.

To me, this reads like you want to say that this is a difficult problem to solve. I don't think it is. And it doesn't have to do with rates.

You either store the volume automation points in dB, then you can simply offset the selected automation points by the same amount. Or you store them as linear scale values in which case you simply multiply all selected points by the same factor. The end result will be the same: moving a bunch of automation points (e.g. 0.0dB, -3dB, -6dB) down a bit will result in the automation points having the same relative values to each other so that the volume relationship (=your mix) remains the same (e.g. the points now changed to -3.0dB, -6.0dB and -9.0dB). This is basic math. You just need to make the right choices when designing this. And they didn't.

Also, editing volume automation with these non-meaningful integer values is really not good. When adjusting an automation point in the sequencer view, all you see is that its value is 453. What does that mean in dB? Well, you have to move the play cursor to that point, then switch over to the rack view and hover the respective fader there to finally be able to read its actual value: -12.58dB. Great, now you want to bump it by +3dB. But what is -9.58dB in this fantasy integer range? Well, nudge up the automation point a bit to maybe 550 in the sequencer view and then back to hovering the fader in the rack view: ah, -7.52dB, too much. Rinse and repeat.

[Pepin]

All non-linear controls will exhibit this issue, because automation data evenly spans the range of the control (knob, fader, etc). [...]

Though ideally, dragging multiple points in this scenario would adjust them at different rates. Other DAWs do this, and mixer faders are a special case where this is more important than elsewhere imo.

To me, this reads like you want to say that this is a difficult problem to solve. I don't think it is. And it doesn't have to do with rates.

You either store the volume automation points in dB, then you can simply offset the selected automation points by the same amount. Or you store them as linear scale values in which case you simply multiply all selected points by the same factor. The end result will be the same: moving a bunch of automation points (e.g. 0.0dB, -3dB, -6dB) down a bit will result in the automation points having the same relative values to each other so that the volume relationship (=your mix) remains the same (e.g. the points now changed to -3.0dB, -6.0dB and -9.0dB). This is basic math. You just need to make the right choices when designing this. And they didn't.

Also, editing volume automation with these non-meaningful integer values is really not good. When adjusting an automation point in the sequencer view, all you see is that its value is 453. What does that mean in dB? Well, you have to move the play cursor to that point, then switch over to the rack view and hover the respective fader there to finally be able to read its actual value: -12.58dB. Great, now you want to bump it by +3dB. But what is -9.58dB in this fantasy integer range? Well, nudge up the automation point a bit to maybe 550 in the sequencer view and then back to hovering the fader in the rack view: ah, -7.52dB, too much. Rinse and repeat.

You seem to think I'm defending the current design, which I'm not. I'm just pointing out that it works identically to every pre-RE device in Reason, so there's not really a bug to report. It's not a great design, obviously.

By "rates" I'm talking about how the points move visually while dragging multiple points vertically. The points would need to move at different rates while dragging in order to maintain their decibel relationships with each other, because the y axis of the automation lane is non-linear. This is exactly how it works in Cubase and elsewhere.

Here's how it looks in Cubase. Notice that points collapse toward each other toward the less "precise" end of the scale. Reason lacks this behavior, because points always move together by the same amount.

CubaseAutomation.gif (153.42 KiB) Viewed 403 times

I'm not claiming any of this is hard to calculate btw, if you got that impression.

[jam-s]

Best workaround so far (sadly) is to open up the fader value to DB mapping table that selig shared some time ago and do a lookup.

[dioxide]

I agree that these values should be actual values not 0-127 or 0-1000. It's also makes Remote feedback virtually useless when I boost an EQ and it reports it as a MIDI value and not in db. They could do better with the Mixer.

[selig]

That is really bad. I'm using the RRP so I'm not affected by this but this should get fixed. Did you ever report this to the devs?

All non-linear controls will exhibit this issue, because automation data evenly spans the range of the control (knob, fader, etc). There's no way to uniformly raise Europa's filter automation by 100Hz either, for instance. It's just less showstopping in that case, because meaningful values are displayed that can still be adjusted one at a time. At a minimum, that could be fixed for the SSL faders.

Though ideally, dragging multiple points in this scenario would adjust them at different rates. Other DAWs do this, and mixer faders are a special case where this is more important than elsewhere imo.

But in this case, the control is LINEAR. It’s a scale of 0-1000, half way up the fader is exactly 500. 3/4 of the way up is 750. The problem is how these values map to decibels, which is not linear, and is different for each and every decibel across the range.

As for the filter example, the filter automation WILL track perfectly in pitch, not frequency (which is what you want). If you automate the filter to step between 100 and 200 Hz (one octave step), then raise or lower all automation levels together the size of the step always remains exactly one octave!

Also, the problem isn’t how Reason deals with automation. Selig Gain easily handles decibel based automation, accurately retaining the exact relationship between values as every other DAW does as automation values are moved up/down as a group. It’s 100% possible to do in Reason, which is why it’s still such a head scratcher.

And we’re pretty much stuck with this behavior since changing it would break every song file in existance.

[selig]

Yea, I do not have a problem with it, I am just OCD and it triggers it hard, especially when setting up a project template.

Dragging a slider and seeing -11.58db on one and -11.53db on another and having to switch my mouse sensitivity to 400dpi instead of 800dpi, just so I can hit the exact # kind of sucks. Also, snapping the main slider to -9db or -6db or -10db or what ever, never happens. It is just annoying more than anything.

There is a workaround for this.
Select both channels a drag the faders together - this will ensure the values are identical. Reset both to 0dB if they get "separated" (command-click Mac), select both channels,, and drag back to the desired position.

[Tiefflieger Rüdiger]

You seem to think I'm defending the current design, which I'm not. I'm just pointing out that it works identically to every pre-RE device in Reason, so there's not really a bug to report. It's not a great design, obviously.

I see. I read it as every control in the world but it was meant as every control in Reason.

And we’re pretty much stuck with this behavior since changing it would break every song file in existance.

As a sequencer, you have two options:
1. Convert legacy data to new data format and fix the range and mapping issue in the affected device (mixer)
2. Add a switch to the affected device to make it accept either the legacy data format or the new data format, then set that switch to the version the data has been created with

This has been done previously by other sequencers and they usually take the first option. As a plugin like VST, you don't have that option. That means you have to ship all code branches forever. It works, too, but it's a bit more painful than the other option.

It's quite sad that they didn't think this would be worth something to their users.

[Pepin]

But in this case, the control is LINEAR. It’s a scale of 0-1000, half way up the fader is exactly 500. 3/4 of the way up is 750. The problem is how these values map to decibels, which is not linear, and is different for each and every decibel across the range.

As for the filter example, the filter automation WILL track perfectly in pitch, not frequency (which is what you want). If you automate the filter to step between 100 and 200 Hz (one octave step), then raise or lower all automation levels together the size of the step always remains exactly one octave!

When I say the control is non-linear, I mean there's a non-linear mapping between the knob position and the meaningful value (decibels). Older devices like Thor and the SSL mixer only show this meaningful value in the tooltip, instead showing the underlying knob position when automated. But even for newer devices like Europa, which show the expected units when automated, the 50% mark when automating is still the halfway point for the underlying knob. This applies to all controls in Reason.

I don't mean to say this behavior is undesired in the Europa example, as it's quite standard behavior for frequency controls (to keep octaves equal size). I'm just pointing out that all non-linear controls behave this way in Reason.

Also, the problem isn’t how Reason deals with automation. Selig Gain easily handles decibel based automation, accurately retaining the exact relationship between values as every other DAW does as automation values are moved up/down as a group. It’s 100% possible to do in Reason, which is why it’s still such a head scratcher.

And we’re pretty much stuck with this behavior since changing it would break every song file in existance.

There is a problem with how Reason deals with editing of fader automation. Just compare it to any DAW that uses non-linear mixer faders but still maintains relationships between control points when editing automation. See the Cubase gif I posted above for how Reason really should behave when editing fader automation.

It's very common for mixer faders to be more "precise" around 0 and less precise further down, but there's seemingly no way to implement such a control in Reason while still preserving the relationships between automated values when dragging multiple points.

The reason Selig Gain does preserve these relationship is that it uses a linear mapping from fader position to decibels. The Trim* fader evenly spans the range from -24 dB to +24 dB, with 0dB at 50%, 12dB at 75% and so on. It's not more precise around 0 like the SSL fader. If you think there are no issues with automation in Reason, then I suppose you mean the SSL mixer should just use linear faders like Selig Gain? Lots of other DAWs make non-linear faders work just fine though, and Reason could too if it was more intelligent in how automation editing was handled. It could be done without breaking any song files, simply by implementing Cubase-style behavior when dragging multiple points. Together with showing the values in decibels, this would fix all the issues being discussed.

*Edit:
It's worth noting only Trim mode is completely nonlinear. VCA mode becomes noticably nonlinear toward -inf. If you create two control points at -70 dB and -30 dB and drag them to the top of the clip, they'll end up at -18 dB and 0 dB. Relationships are mostly preserved, because the control is basically linear except for the steep falloff toward -inf, but it illustrates the same recurring issue.

[selig]

*Edit:
It's worth noting only Trim mode is completely nonlinear. VCA mode becomes noticeably nonlinear toward -inf. If you create two control points at -70 dB and -30 dB and drag them to the top of the clip, they'll end up at -18 dB and 0 dB. Relationships are mostly preserved, because the control is basically linear except for the steep falloff toward -inf, but it illustrates the same recurring issue.

I see what you’re saying (responding to your entire post, just clipped this ‘quote’ to minimize clutter), and I should have pointed out the linear aspects of the control in Selig Gain in my original posts.

I can only imagine it was initially done this way in Reason to save cycles, but to some it may come off as sloppy or lazy programming. It may be one reason why we never saw a trim mode among the automation functions, since it would behave irregularly. And man, I love trim mode when automating and this was one of the limitations that as draw me away from Reason as a mix environment. As a music making environment, there is still nothing that beats Reason for me!

[Tiefflieger Rüdiger]

I can only imagine it was initially done this way in Reason to save cycles, but to some it may come off as sloppy or lazy programming.

To me, it looks like they tried to solve the problem of the UI control being more precise around 0dB and less precise near -inf at the wrong level and made it influence how these values are stored internally. I'm not convinced that this approach saved some cycles back in the days because the amount of mouse events can be expected to be considerably lower than all the operations you have in the DSP part for such a single parameter value. But I'm speculating.

And man, I love trim mode when automating and this was one of the limitations that as draw me away from Reason as a mix environment. As a music making environment, there is still nothing that beats Reason for me!

Probably most Reason users back then didn't had audio engineering features high on their priority list and likely the problems associated with these decisions came up much less than in other DAWs so nobody bothered to fix it yet. Which is a bit ironic since those that pick Reason hoping to have an easier time making music are likely the ones having a harder time to figure this out.

[Pepin]

To me, it looks like they tried to solve the problem of the UI control being more precise around 0dB and less precise near -inf at the wrong level and made it influence how these values are stored internally. I'm not convinced that this approach saved some cycles back in the days because the amount of mouse events can be expected to be considerably lower than all the operations you have in the DSP part for such a single parameter value. But I'm speculating.

I suspect it’s because automation was originally tied directly to MIDI CC values (0-127) that evenly span the relevant knobs. Meaningful tooltips were only added later (Reason 4?), and higher resolution values were added even later (Reason 6?). Despite these improvements, the underlying coupling to control position remained unchanged.

*Edit:
It's worth noting only Trim mode is completely nonlinear. VCA mode becomes noticably nonlinear toward -inf. If you create two control points at -70 dB and -30 dB and drag them to the top of the clip, they'll end up at -18 dB and 0 dB. Relationships are mostly preserved, because the control is basically linear except for the steep falloff toward -inf, but it illustrates the same recurring issue.

Quoting myself to clarify that first sentence should read “linear” not “nonlinear”. Don’t want to confuse anyone more than I already have. Trim mode is completely linear, while VCA mode is nonlinear toward -inf.