"Accuracy" of automation in Reason?

This forum is for discussing Propellerhead's music software. Questions, answers, ideas, and opinions... all apply.
househoppin09
Posts: 536
Joined: 03 Aug 2016

Post 06 Dec 2017

I've seen this mentioned a few times, most recently in the gain-staging thread, where people whose opinion I respect and trust will say something about Reason's automation being too inaccurate or imprecise in some way to be usable for things like gating. However, this makes little sense to me. The automation events seem to have the same precision as anything else in Reason, at least as far as I can tell at first glance. Even if they don't, when snap is enabled, there doesn't seem to be any difficulty in getting automation points to snap perfectly to bar or beat boundaries, or whatever. With that being the case, what exactly is the issue here supposed to be? My eyes and ears seem to be telling me that the gating I do via automation is syncing just fine, nothing sloppy about the results--could I possibly be missing something?

scratchnsnifff
Posts: 1330
Joined: 21 Sep 2016

Post 06 Dec 2017

This is a new one, maybe someone could post an example I’d be interested to see what you mean
Mayor of plucktown :evil:

User avatar
Loque
Posts: 6194
Joined: 28 Dec 2015

Post 06 Dec 2017

I think the automation has the same resolution as CV and this is lower than audio-rate. In most cases it is not a problem. The problem is, that you cannot create a detailed curved automation. Think of a fast pitch curve or some other envelope style automation, where you need to have a fast slope - that is difficult or nearly impossible to create. Some automation is directly related to what the device's resolution offers, like if there are only 127 steps for a filter, you cannot have more and you might hear the steps if you change by 1 instead of "sliding/interpolating" 1 value.
:reason: 11, Win10 64Bit.

Goodbye
Posts: 220
Joined: 21 May 2017

Post 06 Dec 2017

I've been meaning to post about this for a while.

Why is it that the controls in Reason offer such low-resolution? For some reason I've really been noticing this a lot of late. Lots of cases when tweaking and I can clearly hear the change in sound for every step. Maybe it's because I've picked up some good headphones and I'm hearing things better, but I've been quite surprised at how clearly defined these jumps can be.

I'm guessing this is linked to midi, but it doesn't make much sense when tweaking controls from within the DAW itself.

User avatar
ljekio
Posts: 693
Joined: 21 Jan 2015

Post 06 Dec 2017

According to my subjective estimate, Reason can record automation from the midi controller less accurately than other DAWs.
My examples with a breathcontroller or send Curve CV from Matrix back to Reason by loopMIDI convinces me of this.
I would like to make sure the opposite, but not yet.

User avatar
ljekio
Posts: 693
Joined: 21 Jan 2015

Post 06 Dec 2017

2017-12-06 16-24-24 Document 1 .jpg
Rotary 1 automation lane is recording from Matrix curve
Rotary 2 automation lane what create by pencil
You do not have the required permissions to view the files attached to this post.

User avatar
ljekio
Posts: 693
Joined: 21 Jan 2015

Post 06 Dec 2017

Reaper (recorded by loopmidi from Reason's Matrix):
2017-12-06 16-56-06 MIDI take 02-Recorded MIDI.jpg
Reason (import from MIDI file from Reaper):
2017-12-06 16-59-35 testCurve.reason .jpg
I see it as big trouble...
You do not have the required permissions to view the files attached to this post.

User avatar
selig
Moderator
Posts: 8075
Joined: 15 Jan 2015

Post 06 Dec 2017

househoppin09 wrote:
06 Dec 2017
I've seen this mentioned a few times, most recently in the gain-staging thread, where people whose opinion I respect and trust will say something about Reason's automation being too inaccurate or imprecise in some way to be usable for things like gating. However, this makes little sense to me. The automation events seem to have the same precision as anything else in Reason, at least as far as I can tell at first glance. Even if they don't, when snap is enabled, there doesn't seem to be any difficulty in getting automation points to snap perfectly to bar or beat boundaries, or whatever. With that being the case, what exactly is the issue here supposed to be? My eyes and ears seem to be telling me that the gating I do via automation is syncing just fine, nothing sloppy about the results--could I possibly be missing something?
It was something I've heard others say (who are smarter than I am) based on some basic concepts about how a DAW uses available power.
In a DAW, you have to prioritize your CPU "power". The first priority is the audio stream - it must not glitch! The second in Reason is likely the CV signal. The third is probably automation, and the last is screen re-draws. In a perfect world, all four run smoothly without glitches.

But when you begin to run larger song files, the system must prioritize. The first thing to go is the screen re-draws, in many cases the frame rate simply slows down rather than stopping altogether. This can produce 'jitter' in the display since the frame rate is likely not consistent even when it's slowed down. The second to go would be automation, which isn't sample accurate to begin with (I'm not sure the resolution, but it won't line up exactly with the grid in most cases in my experience). When writing hard fader jumps there is a 10-15ms ramp up for the "attack", and 15-20ms for the "release" (which you cannot adjust).

Using Alligator you get control over the envelope, so that's one difference right there. Here's views of automation vs Alligator (automation on top, Alligator below).
Screen Shot 2017-12-06 at 8.18.39 AM.png
Next is "jitter", or the consistency of the timing. This is more difficult to test because you need to push the system to see it. It's also harder to quantify since you may not hear it until it's gone past the point of being a little off. The good news is that when you render, you SHOULD get a perfect render. But again, you don't have control over the attack/release.

What I prefer to do for this and other reasons is to cut the audio itself (for hard cuts/edits) or use a chopper like Alligator/Synchronous etc for repeating patterns. That way you can still make fader changes easily, and add automation moves to your tracks (impossible if you've got the fader jumping up and down).
You do not have the required permissions to view the files attached to this post.
Selig Audio, LLC

User avatar
Ahornberg
Posts: 1766
Joined: 15 Jan 2016
Location: Vienna, Austria

Post 06 Dec 2017

From my experience, by leaving Reason and going over e.g. loopMIDI there will be jitter and latency, at least on Windows systems.

electrofux
Posts: 658
Joined: 21 Jan 2015

Post 06 Dec 2017

I brought this up in the old PUF and if i remember right Ludvig replied explaining it but in the end it is what it is. I think for the really fast stuff it is better to draw the automation yourself or leave it at CV. I think the problem lies on the input side of things. I was recording a stepped pattern from a Thor Sequencer and it didnt sound the same and also showed rising edges where there should only be plateaus.
Last edited by electrofux on 06 Dec 2017, edited 1 time in total.

User avatar
selig
Moderator
Posts: 8075
Joined: 15 Jan 2015

Post 06 Dec 2017

electrofux wrote:
06 Dec 2017
I brought this up in the old PUF and if i remember right Ludvig replied explaining it but in the end it is what it is. I think for the really fast stuff it is better to draw the automation yourself or leave it at CV.
What I've experienced is that it's faster still to use a device for this, since they don't have the limitations of either automation or CV.
Selig Audio, LLC

electrofux
Posts: 658
Joined: 21 Jan 2015

Post 06 Dec 2017

I recall a bit better now ;-)
It is a problem purely when externally recording stepped patterns with big jumps like that Matrix Pattern. Up to 8th notes it was fine but quicker turned out to produce risng /falling edges as interpolation.

Using drawn automation or whatever complex cv device automation poses no problem afaik. I haven't tried what happens when using the pattern to track trick though. And it actually reminds me to have this limitation in mind when deciding to buy the Digitakt eventually ;-)

Goodbye
Posts: 220
Joined: 21 May 2017

Post 06 Dec 2017

I'm confused.

If I (for example) grab the freq slider on a Subtractor and move it, are there actually only 127 possible values? Or are there actually vastly more, but the display is just showing them as 0–127. If the answer is the former and given the huge number-space of 16bit, why are there only 127 possible values?

RandomSkratch
Posts: 415
Joined: 10 May 2016

Post 06 Dec 2017

Goodbye wrote:
06 Dec 2017
I'm confused.

If I (for example) grab the freq slider on a Subtractor and move it, are there actually only 127 possible values? Or are there actually vastly more, but the display is just showing them as 0–127. If the answer is the former and given the huge number-space of 16bit, why are there only 127 possible values?
I'm pretty sure this is correct - this depends on the device. For the Subtractor, yes it's 0-127 but for the SSL mixer fader, I think this is much larger (can't remember what the number is but I saw it posted here once).

chaosroyale
Posts: 267
Joined: 05 Sep 2017

Post 06 Dec 2017

This would be very interesting to get the specs on:
What are the actual resolutions for the main devices in Reason?

Sometimes when pitch bending, adjusting a filter, or "fine" tuning an oscillator, I can hear very obvious steps (which sounds horrible) and I have to think of another way to get the same effect (resampling or whatever).

I would guess automation on things like the SSL or Europa is smoothly interpolating between value "1" and "2" with many more values in between, whereas maybe Subtractor is "stepping" from "1" to "2", but what is the case actually? Any RE developers care to weigh in about their devices? Especially if related to filters and oscillators.

User avatar
selig
Moderator
Posts: 8075
Joined: 15 Jan 2015

Post 06 Dec 2017

Goodbye wrote:
06 Dec 2017
I'm confused.

If I (for example) grab the freq slider on a Subtractor and move it, are there actually only 127 possible values? Or are there actually vastly more, but the display is just showing them as 0–127. If the answer is the former and given the huge number-space of 16bit, why are there only 127 possible values?
Why 127 steps? In the case of the filter, to help tune it to the 127 MIDI notes, I'm guessing.
The internal values are actually 32 bit floating point, so it's up to the dev to decide to quantize them or not.

The extreme version of this is when you turn a control into a 'stepped' control, which means you cannot automate it between two points (each value is a discrete step). The reason to do so would be to make sure the control is always exactly on a specific value, like a semitone control. Look at the difference between the Filter Freq and the Semitone control in Subtractor to see an example.
Screen Shot 2017-12-06 at 2.02.24 PM.png
You do not have the required permissions to view the files attached to this post.
Selig Audio, LLC

Goodbye
Posts: 220
Joined: 21 May 2017

Post 06 Dec 2017

@Selig Thanks. I guess the filter wasn't the best example due to its relationship to pitch. So what about in the case of the envelopes which are also limited to 127 steps plus zero? Are you saying that an LFO for example could set the attack value to a much greater number of values than 127, whilst if you do it with the slider you can only set it to 127 steps within this range values?

If so what does that mean for the combinator. If I route an LFO into CV and have the combinator manipulate the attack, is it constrained by the 127 steps or is the movement of the slider just a visual representation, with the actual value unstepped?

User avatar
selig
Moderator
Posts: 8075
Joined: 15 Jan 2015

Post 06 Dec 2017

Goodbye wrote:
06 Dec 2017
@Selig Thanks. I guess the filter wasn't the best example due to its relationship to pitch. So what about in the case of the envelopes which are also limited to 127 steps plus zero? Are you saying that an LFO for example could set the attack value to a much greater number of values than 127, whilst if you do it with the slider you can only set it to 127 steps within this range values?

If so what does that mean for the combinator. If I route an LFO into CV and have the combinator manipulate the attack, is it constrained by the 127 steps or is the movement of the slider just a visual representation, with the actual value unstepped?
Look at Pulsar as an example, specifically the non-synced rate. If you fine tune it, for example between the default of 8.18 Hz and the values above and below it (8.10 and 8.26 Hz respectively), you skip a few steps. But if you automate, you can type in any value between those, say 8.14 or 8.21 Hz for example). This indicates there are more values "behind the scenes" than the knob can directly address.

As for a Combinator, remember it's simply turning the knob - if the knob can't address all values, neither can the Combinator. You CAN get smaller values by restricting the range of the Rotary to a very narrow range and moving it so you see a specific value on the target device's tool tip display. But the values in the Combinator Programmer also skip, so hitting a specific value take a bit of experimentation.

So like previously mentioned, it depends on how the values are interpreted by the specific device in question.
:)
Selig Audio, LLC

househoppin09
Posts: 536
Joined: 03 Aug 2016

Post 06 Dec 2017

Thanks everyone, this thread is very illuminating. This seems to be an under-discussed aspect of the Reason engine.
selig wrote:
06 Dec 2017
When writing hard fader jumps there is a 10-15ms ramp up for the "attack", and 15-20ms for the "release" (which you cannot adjust).
Fascinating, I never realized this, and it seems like a fairly big deal. To clarify, is this just for the faders on the main mixer, or does this "attack/release" automation phenomenon happen with EVERY control on EVERY Reason device? Or does it depend on the particular control/device? Also, am I correct in thinking that you're saying the finite attack/release phenomenon shows up even in rendered/exported audio, not just real-time output?

User avatar
selig
Moderator
Posts: 8075
Joined: 15 Jan 2015

Post 06 Dec 2017

househoppin09 wrote:
06 Dec 2017
Thanks everyone, this thread is very illuminating. This seems to be an under-discussed aspect of the Reason engine.
selig wrote:
06 Dec 2017
When writing hard fader jumps there is a 10-15ms ramp up for the "attack", and 15-20ms for the "release" (which you cannot adjust).
Fascinating, I never realized this, and it seems like a fairly big deal. To clarify, is this just for the faders on the main mixer, or does this "attack/release" automation phenomenon happen with EVERY control on EVERY Reason device? Or does it depend on the particular control/device? Also, am I correct in thinking that you're saying the finite attack/release phenomenon shows up even in rendered/exported audio, not just real-time output?
I only recorded from one channel to another, and if Reason is consistent it should be that way in all cases. And I only did this for the channel fader, since that was what was being discussed here.
:)
Selig Audio, LLC

RandomSkratch
Posts: 415
Joined: 10 May 2016

Post 06 Dec 2017

If you think about how a console automation is typically used it's usually smooth movements (riding) or you might fully fade up or down a track or two. There's no hard jumps like you find when gating sounds. That's why devices such as alligator are recommended. Or if you want super precise cuts, bounce to audio and edit the wave directly.

househoppin09
Posts: 536
Joined: 03 Aug 2016

Post 06 Dec 2017

selig wrote:
06 Dec 2017
I only recorded from one channel to another, and if Reason is consistent it should be that way in all cases. And I only did this for the channel fader, since that was what was being discussed here.
Ah, okay. I'll run some tests and report back on how widespread it seems to be and whether "export song" is affected. My uninformed suspicion is that it's a "feature" that the Props chose to apply specifically to the main mixer faders, specifically to prevent harsh volume transitions, under the assumption that most users would prefer to have those smoothed over just a bit.

In the meantime, since it's been brought up: I'll add my +1 to everyone who's saying that it's a pain when controls that should have smoothly continuous ranges end up "stepping" in ugly and unexpected ways. This is especially noticeable with filter sweeps. Off the top of my head, I recall it being completely impossible to get a high-resonance filter sweep that doesn't step horribly in the lower part of its range, when using many of the stock Reason devices (SubTractor and NN-XT come to mind, I think?) and things like that can cause major problems. I don't really understand how Reason's parameter value interpolation works. It kind of seems like, on a per-device (or maybe even per-control) basis, interpolation is either activated or deactivated. Or am I misunderstanding entirely? Maybe there's no actual interpolation going on, but what seems like interpolation is just the "hidden higher-resolution values that aren't accessible by turning the knob" thing? I'll need to look more deeply into that, but would be interested to hear what people have figured out thus far.

User avatar
selig
Moderator
Posts: 8075
Joined: 15 Jan 2015

Post 06 Dec 2017

househoppin09 wrote:
06 Dec 2017
selig wrote:
06 Dec 2017
I only recorded from one channel to another, and if Reason is consistent it should be that way in all cases. And I only did this for the channel fader, since that was what was being discussed here.
Ah, okay. I'll run some tests and report back on how widespread it seems to be and whether "export song" is affected. My uninformed suspicion is that it's a "feature" that the Props chose to apply specifically to the main mixer faders, specifically to prevent harsh volume transitions, under the assumption that most users would prefer to have those smoothed over just a bit.

In the meantime, since it's been brought up: I'll add my +1 to everyone who's saying that it's a pain when controls that should have smoothly continuous ranges end up "stepping" in ugly and unexpected ways. This is especially noticeable with filter sweeps. Off the top of my head, I recall it being completely impossible to get a high-resonance filter sweep that doesn't step horribly in the lower part of its range, when using many of the stock Reason devices (SubTractor and NN-XT come to mind, I think?) and things like that can cause major problems. I don't really understand how Reason's parameter value interpolation works. It kind of seems like, on a per-device (or maybe even per-control) basis, interpolation is either activated or deactivated. Or am I misunderstanding entirely? Maybe there's no actual interpolation going on, but what seems like interpolation is just the "hidden higher-resolution values that aren't accessible by turning the knob" thing? I'll need to look more deeply into that, but would be interested to hear what people have figured out thus far.
I'm sure it's a feature applied to any audio level automation, but not sure about other parameters. I'm not where I can put that to the test at present, but will be interested in hearing what you discover.

I'm also interested to hear more about the issues you've mentioned. Are you specifically talking about automation, or does this happen with CV as well? If you have time, maybe create a worst case example, if just to let us know what to avoid! I've pushed things to the point of failure in other areas of Reason, but not (yet) in this one!
:)
Selig Audio, LLC

househoppin09
Posts: 536
Joined: 03 Aug 2016

Post 06 Dec 2017

selig wrote:
06 Dec 2017
I'm sure it's a feature applied to any audio level automation, but not sure about other parameters. I'm not where I can put that to the test at present, but will be interested in hearing what you discover.
I've now done some testing and found that it doesn't work quite the way you thought, though the way it does work makes a certain amount of sense. First of all, I've verified that the "attack/release" thing does indeed show up in the audio rendered by "Export Song/Loop". It appears to be a deliberate aspect of the SSL emulation (though I have no idea whether an actual SSL XL 9000 K behaves similarly). As it turns out, every control on Reason's main mixer responds this way--no instant transitions are possible anywhere. I didn't actually try every single control of course, but I tried a reasonable enough sampling that I'm pretty sure nothing is exempt. The "attack" and "release" times all seem to be somewhere in the general range of 15ms, give or take. Also noteworthy is that, as best I can tell, automation timing IS pretty much perfectly sample-accurate when applied to main mixer controls. In other words, even though it takes ~15 ms for each change to fully kick in, you can see it starting to kick in exactly on-grid, at least when the automation points are snapped to bars or beats. I didn't look extensively enough to be absolutely certain that there are never offsets/jitter/etc., but I wasn't able to see any that struck me as significant. (This is all in the rendered audio, of course.)

Then I took a look at SubTractor. Totally different story--no "attack"/"release" when automating any of the controls, not even the master output level. Everything kicks in instantly, totally unlike the main mixer. At the same time, SubTractor DOES exhibit some timing inaccuracy in where the automation kicks in. I didn't test extensively enough to really nail down all the possible variables, but I was generally seeing the automation kick in anywhere around 3 to 6 ms later than it should. (I did compare this to the note-on/note-off as a sanity check, and those did show up as perfectly on grid, of course!) I'm not really sure what accounts for that delay, and in fact it may have nothing to do with the automation per se; more testing is obviously needed.

I strongly suspect that the behaviors of the main mixer are the idiosyncratic ones, both with respect to the "attack/release" thing and the impressive accuracy of the automation. The SubTractor behavior seems likely to be the norm, at least for the original stock Reason devices (no idea how this would shake out for REs). However, as I haven't tested any other devices yet, that's fairly speculative. As far as my original question about automation accuracy and suitability of automation for gating, I sort of feel like my original intuitions have been vindicated. In the SubTractor (and presumably most other devices), the automation transitions do happen instantly, even for the master level, and the 3 to 6 ms offset (if those numbers hold up) seems usable enough for most ordinary gating purposes, I'd think.

selig wrote:
06 Dec 2017
I'm also interested to hear more about the issues you've mentioned. Are you specifically talking about automation, or does this happen with CV as well? If you have time, maybe create a worst case example, if just to let us know what to avoid! I've pushed things to the point of failure in other areas of Reason, but not (yet) in this one!
I'm mainly talking about automation. CV modulation seems to suffer from a different and less dramatic version of the problem, though it's obviously a lot trickier to check given that only narrow value ranges tend to be affected. Here are instructions that will allow you to easily recreate the automation issue, using the NN-XT filter as an example (SubTractor turns out not to be affected after all). Once you've done that and can hear what I mean, I'll leave it to you to determine the extent to which CV is affected and why it seems to behave somewhat differently, and will be most interested to hear your conclusions. :)

- Create a new NN-XT instance
- Reset it to Init Patch
- Load sample: SH1_SAW_C3.aif from Reason 10 FSB (NN19 Sampler Patches/Synth Raw Elements/Roland SH101 Samples)
- Turn NN-XT Global Filter Res up to max
- Play and hold a note in the bass range (I think I used E2) and try to use automation to smoothly vary the Global Filter Freq from -20 to -15

You should notice awful, extreme stepping with every click of the Filter Freq. This happens regardless of how you modify the parameter--by hand, by remote, automation of any type, with CV being the sole possible exception. I find it very strange that this happens with the NN-XT filter but not the SubTractor filter. What could cause a discrepancy like that? Could this be a genuine bug that affects only some devices based on how their DSP code was written, that has somehow gone undetected all this time?

User avatar
ljekio
Posts: 693
Joined: 21 Jan 2015

Post 06 Dec 2017

@selig , what you can say about my screens?
what could be the matter with it?

  • Information
  • Who is online

    Users browsing this forum: bitley, buddard, lecafard, motuscott, MrFigg and 14 guests