RE delay compensation

[normen]

My bad you did mention the usability, and from a usability perspective I think it can be tricky. Ideally it would be great if it could be automatic, yet at the same time there is a good reason to want control over the behaviour. This could be discussed later as it's a tricky subject that requires a lot of thought and probably can't really be discussed without diagrams and possibly prototypes to see how it feels.



So does this represent what you was saying?



If so, imagine D4 had a plugin delay of 15 frames and D5 had a plugin delay of 20 frames, this would be resolved by the A1->C3 input being delay compensated by 20 frames, A2->C6 input being delay compensated by 35 frames.

Accumulated plugin delay each device (including compensation).
A1 (0)
A2 (0)
C3 (15) - The D5 input comes with 15 frames of accumulated plugin delay, thus the A1 input will be compensated to sync
D4 (35) - Plugin adds 20 frames of plugin delay
D5 (15) - Plugin adds 15 frames of plugin delay
C6 (35) - The D4 input comes with 35 frames of accumulated plugin, thus the A2 input will be compensated to sync

Edit: I might add that until I put this to paper it looked in my head to be unsolvable.

Not quite, but to make it similar you could imagine D4 would have a delay.

Edit: Ah, I thought you painted the delay ridden ones in red. Still the input of A2 should be compensated afterwards? What do you mean by "A2 input"?

[avasopht]

D4 does have a delay in my example, though I've written it wrongly.

It should be:

A1: { adds: 0, inputs: {}, accumulated plugin delay: 0 }
A2: { adds: 0, inputs: {}, accumulated plugin delay: 0 }
C3: { adds: 0, inputs: { A1 (+20 ADC), D5 }, accumulated plugin delay: 20 }
D4: { adds: 15, inputs: { C3 }, accumulated plugin delay: 35 }
D5: { adds: 20, inputs: { A2 }, accumulated plugin delay: 20 }
C6: { adds: 0, inputs: { D4, A2 ( +35 ADC) }, accumulated plugin delay:35 }

In the case of C3, the A1 input has +20 frames of ADC to sync with the D5 input, which has an accumulated plugin delay of 20 frames. D4 adds 15 frames of plugin delay, which when added to the C3 input (with an accumulated plugin delay of 20 frames), has an accumulated plugin delay of 35 frames. The A2->C6 input has +35 frames of ADC to sync with the D4->C6 input.

What do you mean by "A2 input"? 

Oh, that would be the A2 input into C6.

Edit: Thought I'd add that you can test this configuration out in Reason by applying a VMG-01 to the A1->C3 (20 frames) and A2->C6(35 frames).

Also if there were outputs, A7 and A8 connected to C6 and D5 respectively, the D5->A8 connection would have an added ADC of 15 frames.

[Theo.M]

good thread , if Props are really who they are they will not make a shity rack module to cancel that but maybe just do fix the latency propblem .
but yhea it is strange , i guess it's all developement time that they put in other stuff like RE's . 

We've only had serious latency issues since the introduction of perhaps Polar (or maybe Neptune). Taking ProTools as an example, it wasn't until long after a decade before they introduced ADC, and the Reason situation is much more complicated.

Give it time.

Pro tools always displayed the exact latency in the mixer as well as having a sample accurate nudge feature.. it was always very easy to do it manually, 10x as easy as it is to do it in reason. They had the delay compensation plugin yes, that was the VMG equivalent. For those who did not want to do it that way, they simply nudged the affected track back by the number of displayed samples. 

Reason is not sample accurate in nudging so a best approximation can only be done by ear and for example using the regroove mixer for midi.

So sure, PT didn't have ADC till a few years back , but there was no measuring required, and had multiple manual methods to deal with it all of which are quicker than Reason's.

[normen]

D4 does have a delay in my example, though I've written it wrongly.

It should be:

A1: { adds: 0, inputs: {}, accumulated plugin delay: 0 }
A2: { adds: 0, inputs: {}, accumulated plugin delay: 0 }
C3: { adds: 0, inputs: { A1 (+20 ADC), D5 }, accumulated plugin delay: 20 }
D4: { adds: 15, inputs: { C3 }, accumulated plugin delay: 35 }
D5: { adds: 20, inputs: { A2 }, accumulated plugin delay: 20 }
C6: { adds: 0, inputs: { D4, A2 ( +35 ADC) }, accumulated plugin delay:35 }

In the case of C3, the A1 input has +20 frames of ADC to sync with the D5 input, which has an accumulated plugin delay of 20 frames. D4 adds 15 frames of plugin delay, which when added to the C3 input (with an accumulated plugin delay of 20 frames), has an accumulated plugin delay of 35 frames. The A2->C6 input has +35 frames of ADC to sync with the D4->C6 input.

What do you mean by "A2 input"? 

Oh, that would be the A2 input into C6.

Edit

: Thought I'd add that you can test this configuration out in Reason by applying a VMG-01 to the A1->C3 (20 frames) and A2->C6(35 frames).

Also if there were outputs, A7 and A8 connected to C6 and D5 respectively, the D5->A8 connection would have an added ADC of 15 frames.

True, I didn't think about adding a delay on the interconnections in this case. Guess that mainly leaves us with feedback type (be it CV or audio) issues.

[Ostermilk]

good thread , if Props are really who they are they will not make a shity rack module to cancel that but maybe just do fix the latency propblem .
but yhea it is strange , i guess it's all developement time that they put in other stuff like RE's . 

We've only had serious latency issues since the introduction of perhaps Polar (or maybe Neptune). Taking ProTools as an example, it wasn't until long after a decade before they introduced ADC, and the Reason situation is much more complicated.

Give it time.

Pro tools always displayed the exact latency in the mixer as well as having a sample accurate nudge feature.. it was always very easy to do it manually, 10x as easy as it is to do it in reason. They had the delay compensation plugin yes, that was the VMG equivalent. For those who did not want to do it that way, they simply nudged the affected track back by the number of displayed samples. 

Reason is not sample accurate in nudging so a best approximation can only be done by ear and for example using the regroove mixer for midi.

So sure, PT didn't have ADC till a few years back , but there was no measuring required, and had multiple manual methods to deal with it all of which are quicker than Reason's.

Absolutely, although I've said many times I don't find it too difficult to deal with pretty much any situation by using manual adjustment but plenty of times I have to measure and/or compensate outside of Reason to get things spot on.

Certainly how Pro Tools used to display exact latency and better, more accurate means of offsetting tracks would at least be a great improvement in the absence of effective automatic PDC in the rack.

It's fair to say I always manage to deal with latency regardless so it isn't ever an make or break feature for me but it could certainly be made much easier to deal with.

A bigger issue for me which I ought to make a seperate thread for is the fact that I can't edit, quantise, time stretch a group of multi-mic'd tracks as a whole thereby making it absolutely impossible to deal with this type of material without entirely messing up the phase relationships between individual mics/inputs.  That situation always requires using something other than Reason in order to even do it.

[MarkTarlton]

I've said many times I don't find it too difficult to deal with pretty much any situation by using manual adjustment but plenty of times I have to measure and/or compensate outside of Reason to get things spot on.

the problem with this method is say you are using a parallel channel and you are doing some compression/eq/distortion, or whatever floats your boat...you can't actually dial in the sounds in real time while listening to the change in tone, without printing the effect and than moving it, unless you adjust for it with a delay in real time which would require vmg or some other process that totally takes away from making art in the moment as you react to your decisions... which if you have to start thinking about stuff like that you are now a technician and using a different part of your brain, and that takes away the second nature aspect of creating...totally not something I want to have to think about or do. So for now I don't.

[avasopht]

True, I didn't think about adding a delay on the interconnections in this case. Guess that mainly leaves us with feedback type (be it CV or audio) issues.

Pretty much. I do wonder though, how much of a real world problem this is. I mean, it's so easy as a software developer to get caught up in creating the most theoretically correct system when in fact it only matters for 0.001% of cases
I think that's most likely why Reason currently 'resolves' circular references by processing devices in device creation order rather than attempting to create the theoretically minimal batch deferring configuration.

[normen]

Pretty much. I do wonder though, how much of a real world problem this is. I mean, it's so easy as a software developer to get caught up in creating the most theoretically correct system when in fact it only matters for 0.001% of cases
I think that's most likely why Reason currently 'resolves' circular references by processing devices in device creation order rather than attempting to create the theoretically minimal batch deferring configuration.

It has no other chance but to do so because it would actually run forever in one batch if it would follow such a signal flow, that doesn't have much to do with creating the lowest possible delay.

[selig]

Come on then, no more teasing! How are we going to learn if you don't share what you know?

I did share some of my findings on the PUF.

Sorry, but that place is dead to me…

[avasopht]

Pretty much. I do wonder though, how much of a real world problem this is. I mean, it's so easy as a software developer to get caught up in creating the most theoretically correct system when in fact it only matters for 0.001% of cases
I think that's most likely why Reason currently 'resolves' circular references by processing devices in device creation order rather than attempting to create the theoretically minimal batch deferring configuration.

It has no other chance but to do so because it would actually run forever in one batch if it would follow such a signal flow, that doesn't have much to do with creating the lowest possible delay.

HB

What I mean is, there is an algorithm that calculates an optimal processing order to minimise total batch defers.

I'll see if I can find some of my examples tomorrow, and if not I'll just cook one up.

[avasopht]

Come on then, no more teasing! How are we going to learn if you don't share what you know?

I did share some of my findings on the PUF.

Sorry, but that place is dead to me…

Haha, well I posted it a few months ago and never made myself a copy. It went into a lot of detail too and included project files demonstrating deliberate configurations to create predictable handling from reason with the purpose of exposing the underlying business logic inside reason.

[Theo.M]

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.

Bitwig released it totally broken and fixed it in a matter of months with an eigth the amount of employees. Sorry, but I do believe props are on bitwig's coding level, simple as that. It's a situation of allocating resources to do it. 

I believe it is at least 80% possible which would be good enough for most of us. Say direct inserts and parallels. That covers alot of ground. Just implement PDC the way *other* daw's have done it for now.. anything that goes beyond that using reason pasghetti, can stay uncompensated or even easier we just don't use latent effects in those few situations.

[CharlyCharlzz]

good thread , if Props are really who they are they will not make a shity rack module to cancel that but maybe just do fix the latency propblem .
but yhea it is strange , i guess it's all developement time that they put in other stuff like RE's . 

We've only had serious latency issues since the introduction of perhaps Polar (or maybe Neptune). Taking ProTools as an example, it wasn't until long after a decade before they introduced ADC, and the Reason situation is much more complicated.

Give it time.

Pro tools always displayed the exact latency in the mixer as well as having a sample accurate nudge feature.. it was always very easy to do it manually, 10x as easy as it is to do it in reason. They had the delay compensation plugin yes, that was the VMG equivalent. For those who did not want to do it that way, they simply nudged the affected track back by the number of displayed samples. 

Reason is not sample accurate in nudging so a best approximation can only be done by ear and for example using the regroove mixer for midi.

So sure, PT didn't have ADC till a few years back , but there was no measuring required, and had multiple manual methods to deal with it all of which are quicker than Reason's.

one day a guy on the forum explained it all to me on how to just move the audio or midi blocks but then it's really the ears it's easy to airball .

[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.

Bitwig released it totally broken and fixed it in a matter of months with an eigth the amount of employees. Sorry, but I do believe props are on bitwig's coding level, simple as that. It's a situation of allocating resources to do it. 

I believe it is at least 80% possible which would be good enough for most of us. Say direct inserts and parallels. That covers alot of ground. Just implement PDC the way *other* daw's have done it for now.. anything that goes beyond that using reason pasghetti, can stay uncompensated or even easier we just don't use latent effects in those few situations.

Allocation of Resources was exactly my point. Bitwig developed for five years straight (at least). Within these five years Props developed many other things (including the RE SDK) which left them with less time to develop PDC. As I stated many times before, I have zero coding knowledge, so I have no idea what has to go into creating such a thing. But as you say Bitwig had PDC from day1, whereas in Reason it still needs to be implemented. I actually do believe they are working on this since 6.5, but have yet to figure out something, cause I can't see any logical Reason to not research this issue.
Of course I too am looking forward to having it, but I'm fine with waiting until it's ready.

[EnochLight]

Scary thought experiment: let's assume Reason "9" comes out, and the only new big features that appear are:

PDC (that works perfect out of the gate with all RE's)
Some more drag and drop refinements

Would this alone justify a $129 upgrade?

[zakalwe]

no that would be pretty weak.  if they are gonna do frequent upgrades with small feature sets then it would be nice if they could price them accordingly.  i would happily buy upgrades like 8 for around $50 a pop and not think about it too much.  indeed, they may get marginally more money out of me this way if i'm otherwise just going to skip 2 versions because i don't need/rate the upgrades.

[esselfortium]

Scary thought experiment: let's assume Reason "9" comes out, and the only new big features that appear are: PDC (that works perfect out of the gate with all RE's) Some more drag and drop refinements Would this alone justify a $129 upgrade?

In that parallel universe, I would still be on Reason 7.1 for another few years probably.

[CharlyCharlzz]

Talking upgrade price I really think any upgrade would benefite a couple of new RE's from props everytime .

if every year it 's going down with a few changes and a couple Props RE's the full pack will get more and more value .

there is a risk peoples not needing the RE's dont get it for a couple years but the sequencer and other features will still catch him after a couple updates IMO .

are the softtube Amps will still be included in R9 is what I Wonder , If not it will not be fair for the guys like me that will loose line 6 amps and end up with nothing .