Reason 9 is ridicubad...

[jfrichards]

It sounds like a commercial decision, to introduce the instant gratification features...

I am instantly gratified by all the features, even the blue screen (much better than the blue screen of death from the microsoft world.)

[Vyckeil]

i would love to see some videos that demonstrate this issue and methods used to resolve it .. i read these posts and im not afraid to admit that i end up scratching my head , just a little confused, trying to understand he whole latency/PDC thing that people always talk about here ?
im sure im not the only one who is curious to gain a better understanding, maybe its been something that has been happening in my own songs but i just dont realize what it is yet ? lol

All digital audio processing in normal computers needs a bunch of samples to do its work on. For most processing that is exactly your buffer size. If its say 256 samples, the algorithm gets these 256 samples, does its processing and outputs them. Even if you have multiple plugins in a chain, they just pass these 256 samples to each other and do their processing. As long as they do this in time, that is before the next 256 samples come in, everything is fine, if they take longer you get crackles. This buffer time vs. processing time is exactly what your DSP meter is showing btw, and why CPU load is not the same as DSP load.

Some audio processing needs additional time to do processing. Pitch shifting algorithms for example often need a bit more time simply because for example a full 20Hz wave is 50 milliseconds long, so to get the whole wave you need at least 50ms worth of data. Or some limiters and compressors need more time to evaluate if theres peaks coming so they can reduce the level in time without creating artifacts. Some algorithms need high resolution fourier transforms and for higher resolution, especially in the lower frequency ranges, you need more data, i.e. more samples, i.e. more time.

So the result of this is that some plugins don't directly output the 256 samples when the next ones come in, they buffer the data and output it later when they have accumulated more data to do the processing. This means any audio going through these plugins comes out late. This is the "plugin delay" part of "plugin delay compensation".

Now, depending on the additional time the plugin needs this can be in itself a problem. If the delay is so big that audible timing issues arise this is obvious. You don't want your snare drum to be late all the time. But for many things this isn't much of a problem at all. If you have say only 100 or so samples that is only 2 milliseconds of additional delay. Nobody can hear if your snare drum is 2 milliseconds late.

It does however become a problem if you have signals that are strongly related to each other, the most extreme form is having a parallel channel with EXACTLY the same signal. In this case you will get whats called "phase cancellation". Since every audio signal can be seen as an accumulation of sine signals and every sine signal has a certain wavelength, this additional time translates to specific frequencies. So if we look at only one of the sine signals in the mix, what would normally happen if you have a parallel channel is that these two sines would simply add up and you get a signal thats twice as loud (left image). If you now add a delay to the second channel that is exactly half a wavelength of the original channel the two waves completely cancel each other out (middle image).



Since normal music doesn't just consist of single sine waves you get whats called a "comb filter effect" over the whole frequency spectrum, at some points the waves add up, at some points the waves cancel each other out and everything in between, which makes the frequency response look like this:



Again, this is what happens if you mix THE SAME SIGNAL together while one of them has an additional delay, which is the worst case. It can also be a problem if you have signals that are close together and always the same. Say for example a bass drum sample and a bass synth that play together on every downbeat. Because both will look exactly the same each time they are played (if we say the synth patch has no modulation) they will by their nature have some frequencies that add up and some that cancel each other out, defining their sound when mixed together. Now if you delay one of them by adding a plugin with delay these frequencies will shift and the sound will change. This is not so much a problem with real recorded sounds because they are not exactly the same on each beat so they will naturally shift and change anyway.

What plugin delay compensation does now is the following: The DAW knows about the delay of the plugin and simply adds the same delay to the parallel channel. It can also play the recording of the channel where the plugin with delay is a bit sooner but that only works with playback channels so lets ignore that for now. So by adding the same delay to the other channel both channels play exactly in time again and you get no cancellations. In fact DAWs add this delay to all channels in this case so that all channels are "lined up" again.

This is relatively easy to do in most DAWs because they have a simple signal flow from track to channel to bus to output. Its much more complicated in Reason where you can add a loopback to sidechain an effect that was on the same channel, plus you can also have CV routings that go back to the same channel. So in Reason you can always create signal flows that are impossible to resolve through plugin delay compensation - however most "normal" issues can be solved one way or the other automatically. But as said its much more complicated and also more complicated to make it transparent to the user what is actually happening (red is a plugin with delay):

You deserve a medal. That is an awesome post, and I thank you for taking the time to make it. I didn't' even know how hard latency compensation was for Reason until your posted that routing image.

[Creativemind]

i would love to see some videos that demonstrate this issue and methods used to resolve it .. i read these posts and im not afraid to admit that i end up scratching my head , just a little confused, trying to understand he whole latency/PDC thing that people always talk about here ?
im sure im not the only one who is curious to gain a better understanding, maybe its been something that has been happening in my own songs but i just dont realize what it is yet ? lol

This is something I would like to see as well.

[selig]

i would love to see some videos that demonstrate this issue and methods used to resolve it .. i read these posts and im not afraid to admit that i end up scratching my head , just a little confused, trying to understand he whole latency/PDC thing that people always talk about here ?
im sure im not the only one who is curious to gain a better understanding, maybe its been something that has been happening in my own songs but i just dont realize what it is yet ? lol

This is something I would like to see as well.

Do you use Parallel Channels of any sort? If not, you've probably never had an issue. If so, the solution is simple. If you have two parallel paths, and one of them that uses an RE imparts 4 samples of latency while the other that uses no REs imparts NO latency, then you simply add 4 samples to the one with NO latency so they BOTH now have 4 samples of latency. Since they will both have 4 samples of latency, they will be EXACTLY in phase/sync.

There are two ways to add the desired latency to the track with none. The first is to insert the same RE on BOTH channels, but bypass one (doesn't work with every RE, so this is not the best option). The second way is to use Normen's VMG-01 sample delay (set to 4 samples) on the channel with no REs. Make sense?

[AlienJunk]

I would call it Reason Y.

Y? Why Y?

Well because!

You do realise that 'X' is the Roman Numeral for the number 10, right? Its not some random letter (such as Y)

[avasopht]

How common are feedback loops in projects, anyway? If they exist the audio is already out of sync and delayed, so delay compensation might not be anymore complex than what is already going on.

I've been unable to create a setup where delay compensation is impossible to calculate. Might be an interesting question to bring to a graph theorist.

[selig]

I think if they addressed latency compensation for parallel channels they'd address 99% (if not all) of the issues I have with RE induced latency.

[marcuswitt]

I think if they addressed latency compensation for parallel channels they'd address 99% (if not all) of the issues I have with RE induced latency.

Indeed. And IMHO the remaining 1% would be addressed if automatic plugin latency compensation would be applied on Group Channels (Sub Busses) or rather between them.

[Gorgon]

I would call it Reason Y.

Y? Why Y?

Well because!

You do realise that 'X' is the Roman Numeral for the number 10, right? Its not some random letter (such as Y)

[Social Exodus]

There ought to be a way to capture these discussions, and re-release them each time an upgrade is available to Reason as opposed to everyone typing out the same tired arguments pro and/or con about them every time.

[Exowildebeest]

i would love to see some videos that demonstrate this issue and methods used to resolve it .. i read these posts and im not afraid to admit that i end up scratching my head , just a little confused, trying to understand he whole latency/PDC thing that people always talk about here ?
im sure im not the only one who is curious to gain a better understanding, maybe its been something that has been happening in my own songs but i just dont realize what it is yet ? lol

This is something I would like to see as well.

Do you use Parallel Channels of any sort? If not, you've probably never had an issue. If so, the solution is simple. If you have two parallel paths, and one of them that uses an RE imparts 4 samples of latency while the other that uses no REs imparts NO latency, then you simply add 4 samples to the one with NO latency so they BOTH now have 4 samples of latency. Since they will both have 4 samples of latency, they will be EXACTLY in phase/sync.

There are two ways to add the desired latency to the track with none. The first is to insert the same RE on BOTH channels, but bypass one (doesn't work with every RE, so this is not the best option). The second way is to use Normen's VMG-01 sample delay (set to 4 samples) on the channel with no REs. Make sense?

I would regard it as a bug if a RE adds latency when it's bypassed. OchenK's Glitch does this, but I don't know of any others.

[normen]

I would regard it as a bug if a RE adds latency when it's bypassed. OchenK's Glitch does this, but I don't know of any others.

The softube ones do too afaik. As its exactly the same as when they're enabled its kind of a featurebug though.

[Exowildebeest]

I would regard it as a bug if a RE adds latency when it's bypassed. OchenK's Glitch does this, but I don't know of any others.

The softube ones do too afaik. As its exactly the same as when they're enabled its kind of a featurebug though.

I guess it can be a useful "feature" in certain situations... E.g. when automating the bypass, you wouldn't also have to automate the VMG on the original channel. Thus preventing clicks both on mouse and as in audio artifacts.

With all this stuff it always depends on the situation, what you're routing, what you're automating and last but not least what the sounds are.

[selig]

I would regard it as a bug if a RE adds latency when it's bypassed. OchenK's Glitch does this, but I don't know of any others.

The softube ones do too afaik. As its exactly the same as when they're enabled its kind of a featurebug though.

I guess it can be a useful "feature" in certain situations... E.g. when automating the bypass, you wouldn't also have to automate the VMG on the original channel. Thus preventing clicks both on mouse and as in audio artifacts.

With all this stuff it always depends on the situation, what you're routing, what you're automating and last but not least what the sounds are.

That's a great point - I was wondering how this could be a "feature" rather than a "bug", and you've illustrated the point perfectly.

[gak]

This has been the weirdest day. I've been up since 8am (ridicubad-early for me) and have seen it all. 3 traffic accidents, 3 problems with vendors, some dork in GC ruffling my feathers over a street buy (and I didn't want dick for the stuff) not to mention my physical body feeling like I'm transforming into something else.

Then I read all these threads, OMG!

[Creativemind]

It won't be called Reason X 'cause Reason X is ridicubad.

[OverneathTheSkyBridg]

It sounds like a commercial decision, to introduce the instant gratification features...

I am instantly gratified by all the features, even the blue screen (much better than the blue screen of death from the microsoft world.)

That screenshot is exactly why Reason is in desperate need of a scalable rack. Look at those tiny little rack devices! I'm assuming you're working on some mammoth 40" display to have your browser, sequencer, three racks, mixer and spectrum all in one screen and usable. I'm using a second monitor set to 1024 X 768 with which I flip between a full screen rack and mixer.

[jfrichards]

...I'm assuming you're working on some mammoth 40" display ...

I am spoiled by my 27" iMac with 2560x1440. With Command mouse scroll, my Thors are as big as real Moogs.

[Biolumin3sc3nt]

jrichards - I do love the Beard tho - Rock Solid!

[OverneathTheSkyBridg]

...I'm assuming you're working on some mammoth 40" display ...

I am spoiled by my 27" iMac with 2560x1440. With Command mouse scroll, my Thors are as big as real Moogs.

That's actually the same thing I'm running, and I found myself doing the mouse scroll thing quite often. I think I might need glasses.

[pjeudy]

[Ostermilk]

Man if he thinks Reason 9 is gonna make people lazy best not tell him about this...

https://www.jukedeck.com/

LOL

[gak]

Wow, I'm so glad the internet is full of these vids. What WOULD we do w/o them?

Edit, I forgot to add how ridubad that was (and how sorry I am to have wasted my time flipping through it)

[pjeudy]

Man if he thinks Reason 9 is gonna make people lazy best not tell him about this...

https://www.jukedeck.com/

LOL

I will be buying REASON 9 for 2 reasons Scales & Chords and Midi To Audio. People can cry/say it will make producers lazy or too easy to create them Chords all they want...But those same people are Using a Digital Audio Work Station, plugins/RE's ...basically computer softgears

Oh less I forget, I'm not referring to you Ostermilk...I get what you posted! Just wanted to address those same people.

[pjeudy]

and how sorry I am to have wasted my time flipping through it

Don't feel bad..we all waist our time, from time to time, specially flipping through threads that we don't like.