Delay compensation in Reason 8?

[rcyaya]

Has Propellerhead implemented delay compensation yet? I was playing around in my older version of Reason a few nights back because I had not used Reason in a while and I noticed that when I added effects to the dry snare channel from an NN-XT (Pulverizer in this case), it becamely badly delayed from from the room snare channel of the same instance of NN-XT, by maybe a 1/64 of a beat. I could distinctly hear two snare hits, like a flam, where there should have only been one.

If delay compensation hasn't been added yet, how are you guys dealing with that?

Btw, I was surprised to see the Propellerhead forums gone.

[Loque]

Did you set it to full Wet signal processing and do you use Insert or Send effeckts? I am just curious, because i never had any delay-lags, in any Reason version.

[rcyaya]

Did you set it to full Wet signal processing and do you use Insert or Send effeckts? I am just curious, because i never had any delay-lags, in any Reason version.

I'll have to see if I can recreate what I was experimenting with, but I had multiple instances of Pulverizer processing various channels of drums, with no time-based effects going on. I think that wet/dry and insert/send shouldn't make a difference.

[avasopht]

Sounds more like a processing loop, but could be the result of a convolution reverb on dry.

[mguh22]

There isn't any compensation in Reason yet.

The solution to your problem at present is to put a Pulverizer on every output channel of the drums but turn it to 100% dry where you don't want it to alter the audio.

This will ensure all your composite drum parts have equals amounts of delay, keeping them in sync.

[Last Alternative]

^See we shouldn't have to add so much processing for that. Maybe we have no choice right now but I mean come on, PH.. It's 2016!

[rcyaya]

There isn't any compensation in Reason yet.

The solution to your problem at present is to put a Pulverizer on every output channel of the drums but turn it to 100% dry where you don't want it to alter the audio.

This will ensure all your composite drum parts have equals amounts of delay, keeping them in sync.

How would you go about lining the overall drums up with the other tracks? Say I have everything tracked, and I decide to put Pulverizer or some other device that introduces a delay on the drums, and I add dry instances of those devices as necessary so that there ins't any delay among the drums. But now the overall drums are delayed from the other tracks. What would be the easiest way to go about lining the drums back up?

[submonsterz]

Still the best fix in reason thats the easiedt and quickest still to date is to bounce the delayed track to audio.
Then just move back cutting the front end till its on .
Pretty easy with drums to spot the start of the hit on zoom view.

[selig]

There isn't any compensation in Reason yet.

The solution to your problem at present is to put a Pulverizer on every output channel of the drums but turn it to 100% dry where you don't want it to alter the audio.

This will ensure all your composite drum parts have equals amounts of delay, keeping them in sync.

How would you go about lining the overall drums up with the other tracks? Say I have everything tracked, and I decide to put Pulverizer or some other device that introduces a delay on the drums, and I add dry instances of those devices as necessary so that there ins't any delay among the drums. But now the overall drums are delayed from the other tracks. What would be the easiest way to go about lining the drums back up?

Pulveriser has a phase issue that doesn't result in any real delay. But even if the delay is 3 samples such as the Softube devices incur, I would hardly identify this as something that needs to be corrected for in the context of it affecting the groove in a mix.

In fact, you can probably deal with multiple MILLISECOND delays on one element of a mix and not hear any issues. By the time you get into double digits the delays can cause issues, but only in my experience if you're talking about two different transient heavy elements, like the drums and some heavy percussion or extremely plucky arpeggiated synth line. Even then, it's all contextual - sometimes I've actually felt the groove was improved by a slight delay on a track (talking 10-20 ms range).

Sure, you can go through and try to correct for the single-digit sample length delays, but you'll never hear them EXCEPT for on phase coherent tracks (delaying one track of a group of multi-mic'ed drums, for example). Folks slide tracks intentionally all the time to improve the groove, but are more often doing it by milliseconds not samples. As always, YYMV and you should always judge things like this in context.

[Osmose]

Im in the ball park with selig, though i'd like to add that the "flam" issue occurs on parallek channels, like the snare that was mentioned as an example. Thus only the channel, after the split to a parallel channel needs to get some delaying to compensate the issue. Not additional channels.

Verstuurd vanaf mijn HUAWEI P7-L10 met Tapatalk

[selig]

Im in the ball park with selig, though i'd like to add that the "flam" issue occurs on parallek channels, like the snare that was mentioned as an example. Thus only the channel, after the split to a parallel channel needs to get some delaying to compensate the issue. Not additional channels.

Verstuurd vanaf mijn HUAWEI P7-L10 met Tapatalk

If there's a flam, it's not coming from the Pulveriser on a parallel channel…

[michal22]

Unfortunately, there is still no delay compensation. It is very unpleasant. Propellerhead constantly chasing competition. It is 2016 years and delay compensation is the basic technique of good sound when we mixing parallel channels. This should be introduced together with the launch of parallel channel for me.

[selig]

Unfortunately, there is still no delay compensation. It is very unpleasant. Propellerhead constantly chasing competition. It is 2016 years and delay compensation is the basic technique of good sound when we mixing parallel channels. This should be introduced together with the launch of parallel channel for me.

While I agree with the idea that delay compensation on parallel channels would be a good idea, in the case of the OP I'm just saying that adding a parallel channel and a pulveriser will not add any delay, so no need for delay compensation in this case. Just to be clear…

[michal22]

While I agree with the idea that delay compensation on parallel channels would be a good idea, in the case of the OP I'm just saying that adding a parallel channel and a pulveriser will not add any delay, so no need for delay compensation in this case. Just to be clear…

Yes. You are right. I just checked it. In my opinion, a good idea might be that each RE must have a fixed delay, for example 20 samples. Then there was it would be necessary to make compensation. All plugs will work on a delay established by Propellerhead.
This is feasible because Propellerhead implements to the store and has control over all extensions. They can give such requirements.

[michal22]

I write stupidity. I had not thought about the chain of plug-ins. Excuse me. I'm tired.

[Osmose]

Im in the ball park with selig, though i'd like to add that the "flam" issue occurs on parallek channels, like the snare that was mentioned as an example. Thus only the channel, after the split to a parallel channel needs to get some delaying to compensate the issue. Not additional channels.

Verstuurd vanaf mijn HUAWEI P7-L10 met Tapatalk

If there's a flam, it's not coming from the Pulveriser on a parallel channel…

Didn't nescesarily meant Pulverizer, just delay issues in parralel channels in general They do occur to me in some occasion

[selig]

Im in the ball park with selig, though i'd like to add that the "flam" issue occurs on parallek channels, like the snare that was mentioned as an example. Thus only the channel, after the split to a parallel channel needs to get some delaying to compensate the issue. Not additional channels.

Verstuurd vanaf mijn HUAWEI P7-L10 met Tapatalk

If there's a flam, it's not coming from the Pulveriser on a parallel channel…

Didn't nescesarily meant Pulverizer, just delay issues in parralel channels in general They do occur to me in some occasion

Yes, me too, typically 3 samples with Softube stuff. But on all non-parallel channels this extremely short delay would never be noticed, groove wise, let alone cause "flams", which are typically anywhere from 40-60 ms, or 1700 to 2600 samples at 44.1kHz…

[Osmose]

Im in the ball park with selig, though i'd like to add that the "flam" issue occurs on parallek channels, like the snare that was mentioned as an example. Thus only the channel, after the split to a parallel channel needs to get some delaying to compensate the issue. Not additional channels.

Verstuurd vanaf mijn HUAWEI P7-L10 met Tapatalk

If there's a flam, it's not coming from the Pulveriser on a parallel channel…

Didn't nescesarily meant Pulverizer, just delay issues in parralel channels in general They do occur to me in some occasion

Yes, me too, typically 3 samples with Softube stuff. But on all non-parallel channels this extremely short delay would never be noticed, groove wise, let alone cause "flams", which are typically anywhere from 40-60 ms, or 1700 to 2600 samples at 44.1kHz…

Yep, my experience as well. Gives a nice bit of extra swing indeed.
Being bugged with it probably has more to do with being a controlfreak then it actually being a issue[emoji14]

Verstuurd vanaf mijn HUAWEI P7-L10 met Tapatalk

[rcyaya]

There isn't any compensation in Reason yet.

The solution to your problem at present is to put a Pulverizer on every output channel of the drums but turn it to 100% dry where you don't want it to alter the audio.

This will ensure all your composite drum parts have equals amounts of delay, keeping them in sync.

How would you go about lining the overall drums up with the other tracks? Say I have everything tracked, and I decide to put Pulverizer or some other device that introduces a delay on the drums, and I add dry instances of those devices as necessary so that there ins't any delay among the drums. But now the overall drums are delayed from the other tracks. What would be the easiest way to go about lining the drums back up?

Pulveriser has a phase issue that doesn't result in any real delay. But even if the delay is 3 samples such as the Softube devices incur, I would hardly identify this as something that needs to be corrected for in the context of it affecting the groove in a mix.

In fact, you can probably deal with multiple MILLISECOND delays on one element of a mix and not hear any issues. By the time you get into double digits the delays can cause issues, but only in my experience if you're talking about two different transient heavy elements, like the drums and some heavy percussion or extremely plucky arpeggiated synth line. Even then, it's all contextual - sometimes I've actually felt the groove was improved by a slight delay on a track (talking 10-20 ms range).

Sure, you can go through and try to correct for the single-digit sample length delays, but you'll never hear them EXCEPT for on phase coherent tracks (delaying one track of a group of multi-mic'ed drums, for example). Folks slide tracks intentionally all the time to improve the groove, but are more often doing it by milliseconds not samples. As always, YYMV and you should always judge things like this in context.

I figured out that the doubling I was hearing isn't a latency issue at all. With some combinations of compression settings the timing of multiple compressors (on probably any compressor) can create an almost doubling effect, and it seems to be most noticeable on sources with loud transients, such as snare drums. I never noticed it before, but with pulverizer I was destructing the snot out of some drums, which is something that I don't usually do. I figured out what was going on after doing some similar smashing with a vst compressor. What it sounds like is a snare hit, very quickly followed by a light ghost hit.