RE delay compensation

[djfm1983]

I can't believe that PHeads haven't implemented this after version Record 1.0. I hate it when your using REs on individual drum channels and your whole drum beat is out of sync. If you use their parallel channels it's pointless to use REs unless you have Norman's RE, but come on who wants to put that RE on every channel and take the time to make sure every channel is in sync with each other (talk about workflow disruption). I can see if your only using a few channels but for someone like me who can easily reach 40+ track count when including vocals in a song it's too much of a hassle. I'd have get out a piece of paper, find out the latency for each channel and find out how much I need to delay each channel so they match up. I'm hoping for them to finally implement RE delay compensation but until then I'm done mixing in Reason.

[Wook]

I guess it's a batch for them to incorporate it because of all that Reason spaghetti in the back. I'm waiting to see how Bitwig handles modularity with all the external vst's. After that, Propellerheads have no excuses.

[djfm1983]

I guess it's a batch for them to incorporate it because of all that Reason spaghetti in the back. I'm waiting to see how Bitwig handles modularity with all the external vst's. After that, Propellerheads have no excuses.

I think it's possible for them to implement it, they probably rather spend time working on new iOS apps and PHeads REs then reworking the whole Reason code. I think PHeads have no excuse as of right now.

[Gaja]

Even if bitwig have it figured out, doesn't mean props can simply do the same. Bitwig developers will probably not make their code publicly available. Also don't forget that during the time bitwig was in development (at least 2009) props have been very busy developing all kinds of awesome stuff along with doing their research. So bitwig developers have had tons of time to actually have all the people develop the compensation algorithms.
So this whole no excuse business is kind of not doing it for me....
Off course I'd like automatic plugin delay compensation, but I'm fine with the VMG-01 so far. If what I want to do is worth it then I'll take my time wih a pencil and actually scratch a piece of paper to calculate the delays.

[normen]

Yeah, as people said, its not as easy in Reason to have "full PDC" as it is in other DAWs, Other DAWs just have the signal flow from channel to bus to master, in Reason you can do anything. Lemme pull out my trusty badly drawn example  :s0403:

[djfm1983]

Yeah, as people said, its not as easy in Reason to have "full PDC" as it is in other DAWs, Other DAWs just have the signal flow from channel to bus to master, in Reason you can do anything. Lemme pull out my trusty badly drawn example:

Your probably right Norman, I guess I'm just frustrated because I feel like in this day and age they should be able to figure it out if they work at it long enough. I guess if what your saying is true then Reason will never have a working RE DC. At least someone like you was smart enough to build a RE for people to put their tracks in sync. As for me whenever I reach a higher track count it becomed such a hassle to find each channels delay, see which channels is delayed the longest and subtract each channels delay from the longest delay, then add the result to each channels as required. It's annoying too because each time you add a RE this needs to be done if you want everything in sync.

[normen]

Your probably right Norman, I guess I'm just frustrated because I feel like in this day and age they should be able to figure it out if they work at it long enough. I guess if what your saying is true then Reason will never have a working RE DC. At least someone like you was smart enough to build a RE for people to put their tracks in sync. As for me whenever I reach a higher track count it becomed such a hassle to find each channels delay, see which channels is delayed the longest and subtract each channels delay from the longest delay, then add the result to each channels as required. It's annoying too because each time you add a RE this needs to be done if you want everything in sync.

Sure, I can get the frustration (and the problem, obviously thats why I did the VMG-01 ) and afaik the Props are working on this problem. Theres *some* things that can be done but you'll always be able to make signal flows that simply can't be compensated in Reason and we have to cut them some slack because it *is* more complicated than in other DAWs. I'm sure they'll add something to at least make channels that are used in the same manner as in other DAWs run in sync eventually.

[djfm1983]

Your probably right Norman, I guess I'm just frustrated because I feel like in this day and age they should be able to figure it out if they work at it long enough. I guess if what your saying is true then Reason will never have a working RE DC. At least someone like you was smart enough to build a RE for people to put their tracks in sync. As for me whenever I reach a higher track count it becomed such a hassle to find each channels delay, see which channels is delayed the longest and subtract each channels delay from the longest delay, then add the result to each channels as required. It's annoying too because each time you add a RE this needs to be done if you want everything in sync.

Sure, I can get the frustration (and the problem, obviously thats why I did the VMG-01 ) and afaik the Props are working on this problem. Theres *some* things that can be done but you'll always be able to make signal flows that simply can't be compensated in Reason and we have to cut them some slack because it *is* more complicated than in other DAWs. I'm sure they'll add something to at least make channels that are used in the same manner as in other DAWs run in sync eventually.

I sure hope so.

[The Tone Ranger]

I do it the old fashioned way and move the audio on the delayed tracks back so it's in sync. That seems a lot easier if you only have a few problem tracks. Polar is the only RE that causes me any problems and that's not something I use a lot of.

[djfm1983]

I do it the old fashioned way and move the audio on the delayed tracks back so it's in sync. That seems a lot easier if you only have a few problem tracks. Polar is the only RE that causes me any problems and that's not something I use a lot of.

I don't mind moving things around when I'm only using a few tracks (hip hop beats come to mind), but when I'm producing EDM it can become a burden to keep everything in sync.

[Exowildebeest]

As I see it, there are two different kinds of latency compensation situations:

1. General track timing related latency, e.g. vocals that are a bit off due to the large latency of processing like Neptune/Polar. In these cases, shifting the track by ear in the sequencer or with Regroove will do.

2. Parallel processing latency that causes phase problems (as opposed to the rhythmic timing problems in 1.) This kind of latency starts at much lower time intervals and requires the VMG for corrections in samples, this can't reliably be done in the sequencer or Regroove.

If Propellerheads ever does something about this, all I can see them doing is integrating VMG or their own device into Reason, and nothing more.

[avasopht]

As I see it, there are two different kinds of latency compensation situations:

1. General track timing related latency, e.g. vocals that are a bit off due to the large latency of processing like Neptune/Polar. In these cases, shifting the track by ear in the sequencer or with Regroove will do.

2. Parallel processing latency that causes phase problems (as opposed to the rhythmic timing problems in 1.) This kind of latency starts at much lower time intervals and requires the VMG for corrections in samples, this can't reliably be done in the sequencer or Regroove.

If Propellerheads ever does something about this, all I can see them doing is integrating VMG or their own device into Reason, and nothing more.

Nah it's possible for them to implement full automatic PDC. I've written most of the *algorithm in psuedo and diagrams that calculates the respective delay compensation for the entire chain.

One of the tough issues might be whether they let the user to be involved in some of the feedback loop decisions as to which devices take priority over which. Currently it seems to be based on device creation order. 

They will want to test out which of those options feels best and also decide whether it's worth going through the grand effort of calculating a minimal automatic PDC (one that yields the lowest plugin delay by prioritising devices in an optimal way).

*: for my own personal use (not for Propellerhead )

[michal22]

Great topic.
I am all for the author of the thread.
It is very annoying in large projects.

I think that you need to do a limited version of delay compensation.
What I mean is that the compensation is for the whole channel, regardless of content.
If we in the "combinator" we process the signal in parallel then we use VMG.
Automatic delay compensation only checks the first impulse of the whole audio channel mixer SSL.
I think that this can be done.
In addition, I would like to have a knob for manual manipulation of delay.

[normen]

The REs do have to report their latency so theres no need to measure anything (the VMG can't access this info though). Still, if Reason was to decide what to do in unresolvable situations that would be a mess, how am I as a user supposed to know what Reason decided it should do? I don't think its quite as easy as @avasopht says.

[avasopht]

Reason currently has a policy on how it handles feedback loops by prioritising device processing.

Calculating delay from that position iirc was a fairly straight forward algorithm.

I would have to build a configuration generator to confirm the processing cost on larger setups and also to test the algorithm and make sure the problem isn't more complex.

[normen]

Reason currently has a policy on how it handles feedback loops by prioritising device processing. Calculating delay from that position iirc was a fairly straight forward algorithm. I would have to build a configuration generator to confirm the processing cost on larger setups and also to test the algorithm and make sure the problem isn't more complex.

Resolving it in some way isn't the big deal, the big deal is making transparent what actually happens because the "impossible" delays will crop up somewhere. 

[selig]

I'm one of those (maybe in a small minority?) who would be perfectly happy if they added ADC only to parallel channels since that's the only time it affects my work flow. All channels which are parallel can be easily identified by the software, and all REs are required to report their latency. Going beyond that is where things can get "sticky" IMO.

Sadly for Normen, this would make his excellent RE less useful to many (sorry Normen). But hey, I'd also be the first one celebrating if the Props updated the SSL mixer to make my Gain RE less useful as well!

[normen]

I'm one of those (maybe in a small minority?) who would be perfectly happy if they added ADC only to parallel channels since that's the only time it affects my work flow. All channels which are parallel can be easily identified by the software, and all REs are required to report their latency. Going beyond that is where things can get "sticky" IMO.

Sadly for Normen, this would make his excellent RE less useful to many (sorry Normen). But hey, I'd also be the first one celebrating if the Props updated the SSL mixer to make my Gain RE less useful as well!

Hehe, I was never in for the money, I did the plugin because I wanted it for myself. I'd be happy if they added this solution as well. Theres still no better way to test the actual roundtrip latency of your audio interface in Reason though  

[MarkTarlton]

I would be fine with ADC on parallel channels only. It would solve at least some of my latency problems when trying to mix in Reason. However you would still be dealing with phase issues on inserts and than there is the issues when tracking and you want to add a quick effect on the vocal channel but first you have to make a parallel...which means your sessions can start to get complicated really quick and dsp is still an issue. BUT at least I could do my buss mixing tricks

[avasopht]

Resolving it in some way isn't the big deal, the big deal is making transparent what actually happens because the "impossible" delays will crop up somewhere. 

But they already deal with feedback loops with somewhat predictable behaviour. Even without RE's Reason has always had to deal with those and I can't imagine it being a bigger problem with ADC than without because if you get one you know why, you have a feedback loop.

That is though, why I said they would want to test out different policies for feedback loops. I think manual configuration by the user would be too much beyond perhaps device positioning or wiring order.

[normen]

But they already deal with feedback loops with somewhat predictable behaviour. Even without RE's Reason has always had to deal with those and I can't imagine it being a bigger problem with ADC than without because if you get one you know why, you have a feedback loop.

That is though, why I said they would want to test out different policies for feedback loops. I think manual configuration by the user would be too much beyond perhaps device positioning or wiring order.

Wheres the actual need for a feedback loop though?

Reminds me of this guy standing in the line in front of me in a music store.. He said he got a feedback when he pulled up the aux send on the channel where he put the return of his reverb and asked for a feedback destroyer for that

[MarkTarlton]

But they already deal with feedback loops with somewhat predictable behaviour. Even without RE's Reason has always had to deal with those and I can't imagine it being a bigger problem with ADC than without because if you get one you know why, you have a feedback loop.

That is though, why I said they would want to test out different policies for feedback loops. I think manual configuration by the user would be too much beyond perhaps device positioning or wiring order.

Wheres the actual need for a feedback loop though?

Reminds me of this guy standing in the line in front of me in a music store.. He said he got a feedback when he pulled up the aux send on the channel where he put the return of his reverb and asked for a feedback destroyer for that

you definitely don't want to do that cuz that is the good kind of feedback

[avasopht]

Wheres the actual need for a feedback loop though?

Reminds me of this guy standing in the line in front of me in a music store.. He said he got a feedback when he pulled up the aux send on the channel where he put the return of his reverb and asked for a feedback destroyer for that

Well feedback loops are the problem connections that probably only come about by accident.

I only consider them because they can be made and initially I wanted to see how Reason dealt with it.

[Theo.M]

I certainly wouldn't be happy with a parallel's only PDC, sorry guys.

I *would* be happy with a limited "left to right" structure PDC.. i.e for audio tracks and instruments and their inserts and then going to busses going to the master out.. like any other daw's signal flow basically..for inserts that are not using cv cables and perhaps not for combinators, but it is not hard to limit combinators to latency free devices.

Then i would like automation shifting to be supported by this as well as visual compensation so the playhead is in time with the audio.

So basically, a fairly comprehensive PDC at the same level as every other DAW that is on the market today would be OK, and a start. They can add the modular free routing "any scenario" pdc at a later date, IMO. 

It would be easy to know what is compensate-able.. a track could have some sort of icon on it to say it is not compensated as it "breaks the PDC laws" or something like that.. Normen did sayRE's already report their latency so this feature could come into play the moment an RE is inserted that has latency, and if it is in a configuration that is not automatically compensated. Say a little exclamation mark or something.

One thing is for sure.. Any resulting bounced audio can be compensated by offsetting it back to the correct time, right? So that means theoretically there has to be a way, as the programming is already calculating  the signal path and bouncing it with the latency, isn't it? 

Plus, Bitwig did it, and they did it in a few months, with a team less than 1/5th the size of props.

I firmly believe, like avasopht, that this can be done if they decided to do it.

I also believe that they simply decided to prioritise other stuff, like mobile apps and discover. Do you really think if they didn't spend all those resources doing those things and had focused them all into putting PDC for Reason, that it couldn't have been done by now? 

What I also find disappointing is the magazine reviews never mention it, like Reason has a pass. It's aiming for the same DAW market as most other DAW's now and should be compared as such. I bet if they get some bad publicity about it from a couple of the top music mags that things might change.

That said, Normen said "afaik they are working on it"... maybe you can't say more but you must have realised that that comment would create some curiosity/anticipation/perhaps even excitement in some of us.. So i ask.. is this just a speculative guess or do you have some real info that they are doing something about it?

[normen]

Theres always possible situations where the latency simply can NOT be compensated, as my little drawing shows, you don't even need a feedback loop for that. You'd theoretically have to bounce the whole signal flow an infinite amount of times to compensate that, so mathematically its possible, technically its not. There won't be even one bounce-through, it has to be solved "live". The problem I'm describing is that you as a user don't know whats happening anymore, the "unsolvable" delay will be *somewhere* in your signal flow, be it in your sidechained compressor, your CV routing to a synth or somewhere else, it will be immensely confusing and you all know that you can already easily confuse yourself with a signal flow in Reason That said, for the "simple" signal flow its definitely possible to compensate and I'm sure there'll be a solution eventually (sorry @Theo ).