RE delay compensation

[avasopht]

But your diagram contains a feedback loop (or at least a circular reference, which is the real problem).

You can't compensate for the delay, no, but in those cases you simply defer to the next batch according to the prioritisation process, which is currently device creation order in Reason. There is a more sophisticated algorithm for finding the minimal overall delay compensation, but I think it may be unnecessary.

We'll only know by seeing a large number of real life samples as to how much of a real world problem this actually is.

But if you would like to provide me with a sample set (using whatever format you wish, preferably text based), I'll happily use it to challenge my algorithm and post the results.

It's possible that many people may be creating circular references in a flawed attempt at automating parameters.

I think though, I ought to get the ball rolling with some code to show you guys.

[normen]

But your diagram contains a feedback loop (or at least a circular reference, which is the real problem).

You can't compensate for the delay, no, but in those cases you simply defer to the next batch according to the prioritisation process, which is currently device creation order in Reason. There is a more sophisticated algorithm for finding the minimal overall delay compensation, but I think it may be unnecessary.

We'll only know by seeing a large number of real life samples as to how much of a real world problem this actually is.

But if you would like to provide me with a sample set (using whatever format you wish, preferably text based), I'll happily use it to challenge my algorithm and post the results.

It's possible that many people may be creating circular references in a flawed attempt at automating parameters.

I think though, I ought to get the ball rolling with some code to show you guys.

That doesn't have to be an actual feedback loop, it can just be a sidechain or a vocoder input or a CV routing.

[avasopht]

That's what I meant when I said, "it's possible that many people may be creating circular references in a flawed attempt at automating parameters."

I'd factored that in too.

[normen]

That's what I meant when I said, "it's possible that many people may be creating circular references in a flawed attempt at automating parameters."

I'd factored that in too.

Why would that have to be flawed? And you can't solve these situations, the delay will be somewhere, how does the user know where it is?

[avasopht]

I saw flawed as it's possible (even likely) they're not expecting there's a 64 frame delay that is out of their control.

In terms of how the delay will be compensated, in that case it won't. In terms of how the user knows where it is, it will be dealt with in the exact same way it currently is now, one device takes priority and the remainder gets processed on the next batch.

[normen]

I saw flawed as it's possible (even likely) they're not expecting there's a 64 frame delay that is out of their control.

In terms of how the delay will be compensated, in that case it won't. In terms of how the user knows where it is, it will be dealt with in the exact same way it currently is now, one device takes priority and the remainder gets processed on the next batch.

There is no "next batch" if the device delay is arbitrary. And you're still only talking about the "feedback" situation.

[avasopht]

I saw flawed as it's possible (even likely) they're not expecting there's a 64 frame delay that is out of their control.

In terms of how the delay will be compensated, in that case it won't. In terms of how the user knows where it is, it will be dealt with in the exact same way it currently is now, one device takes priority and the remainder gets processed on the next batch.

There is no "next batch" if the device delay is arbitrary. And you're still only talking about the "feedback" situation.

Have you examined how reason currently deals with this scenario?

When you look into this deeply you'll see that all that is left is calculating delay compensation through a somewhat straight forward algorithm (especially when you consider how reason currently handles this).

It's something I pushed to it's limits to identify the exact behaviour.

I've even find bugs in their current algorithm through it when attempting to create a gate that operated in the same batch.

[avasopht]

PS, there most certainly is a next batch. You'll see this when you experiment. I'll upload a file later today for classification on what I mean as it's easy for miscommunication.

[normen]

Have you examined how reason currently deals with this scenario? When you look into this deeply you'll see that all that is left is calculating delay compensation through a somewhat straight forward algorithm (especially when you consider how reason currently handles this). It's something I pushed to it's limits to identify the exact behaviour. I've even find bugs in their current algorithm through it when attempting to create a gate that operated in the same batch.

Yes in situations where there is feedback loops, you don't need a feedback loop to create issues like these, a simple row of sidechains between channels that have plugins with delay in different parts of the signal chain is enough.

[avasopht]

And what do you find reason doing in that case?

[normen]

And what do you find reason doing in that case?

It has the delays where one would expect them according to the signal flow.

[avasopht]

There's more to it than that. Reason has a policy for deciding which device takes priority and is processed first. Have you identified what that policy is? (I have identified it).

Secondly, how do you imagine the case of ADC would be complicated? Have you constructed any test models to see whether anything could be deterministically calculated? (I have).

I'm not just a dreamer FYI, I've researched this extensively I'm a graph theory guy. Not the best in the world, but this is one of my areas of interest

Maybe you've identified a simple configuration that is impossible for ADC to be calculated, ...

[selig]

There's more to it than that. Reason has a policy for deciding which device takes priority and is processed first. Have you identified what that policy is? (I have identified it).

Secondly, how do you imagine the case of ADC would be complicated? Have you constructed any test models to see whether anything could be deterministically calculated? (I have).

I'm not just a dreamer FYI, I've researched this extensively I'm a graph theory guy. Not the best in the world, but this is one of my areas of interest

Maybe you've identified a simple configuration that is impossible for ADC to be calculated, ...

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

[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. I'm hoping *Reason101 saved it as I did give him a link for the thread to preserve it.

I may revisit the ADC code in the next few weeks as a side project for some mental exercise.

*: really should have saved it myself, thought I had backed it up somewhere but I didn't :frown:

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

[avasopht]

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.

[Purpleb]

Love this thread, probably one of the best on RT.

[Exowildebeest]

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

I disagree - latency with Polar and Neptune is the kind of large latency that's easily compensated for manually, when it comes to rhythmic timing, when they're used as 100% wet inserts.

It's stuff like Saturation Knob, compressors etc. with their few samples of latency, devices that are often used in parallel, and thus cause phasing, that really made the issue of latency compensation apparent. Those issues needed the VMG for fixing - there was no other practical way.

[Heater]

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.

From a code point of view it would have thought it would be relatively simple.  You could send an time stamped sample thru the entire channel and start a counter, wait for it to come out the other end and subtract one the other.  That's the delay compensation required.

Adjust the other tracks relative to the longest delay.

A simple switch on the transport control would be all that's required.

I'm probably missing something fundamental here

[Exowildebeest]

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.

From a code point of view it would have thought it would be relatively simple.  You could send an time stamped sample thru the entire channel and start a counter, wait for it to come out the other end and subtract one the other.  That's the delay compensation required.

Adjust the other tracks relative to the longest delay.

A simple switch on the transport control would be all that's required.

I'm probably missing something fundamental here

That's what the VMG does - but to automate this process, you'll have to find an algorithm/code that does this automatically at every change the user makes. The algorithm would also have to detect feedback loops and possibly disable those connections or decide what to do - which begs the question of what feedback about that, i.e. about the decisions the algorithm makes, is provided to the user. Could be in the form of warning, error messages, or whatever, which already makes it come closer to semi-automatic instead of fully automatic.

[Heater]

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.

From a code point of view it would have thought it would be relatively simple.  You could send an time stamped sample thru the entire channel and start a counter, wait for it to come out the other end and subtract one the other.  That's the delay compensation required.

Adjust the other tracks relative to the longest delay.

A simple switch on the transport control would be all that's required.

I'm probably missing something fundamental here

That's what the VMG does - but to automate this process, you'll have to find an algorithm/code that does this automatically at every change the user makes. The algorithm would also have to detect feedback loops and possibly disable those connections or decide what to do - which begs the question of what feedback about that, i.e. about the decisions the algorithm makes, is provided to the user. Could be in the form of warning, error messages, or whatever, which already makes it come closer to semi-automatic instead of fully automatic.

I don't think feedback loops would be a problem.  You look for the first instance of the uniquely timestamped sample to exit the channel and record the delay.  Any other samples with the same time stamp that is being repeated or feeding back that finally finds it's way to the exit point would be ignored.

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

I was just saying it is weird and also that if they are going to fix this it was not going to be a Rack module.

no hurry for me , if I nêeded it I would just buy Normen RE but I would not know how to use it ,
it's the type of stuff I  would rather having the DAW doing for me before I ear it .

[normen]

There's more to it than that. Reason has a policy for deciding which device takes priority and is processed first. Have you identified what that policy is? (I have identified it).

Secondly, how do you imagine the case of ADC would be complicated? Have you constructed any test models to see whether anything could be deterministically calculated? (I have).

I'm not just a dreamer FYI, I've researched this extensively I'm a graph theory guy. Not the best in the world, but this is one of my areas of interest

Maybe you've identified a simple configuration that is impossible for ADC to be calculated, ...

Oh, you think I'm disagreeing with you or calling you a dreamer, sorry for that.. I thought I repeatedly said its about usability and not theory. I also thought you agreed already that there was situations where the "correct" way to solve the latency wasn't possible... Anyway here goes..

So imagine a channel where you have one compressor, then a plugin with delay, then another compressor. Then theres another channel after that with a plugin with delay. Now you feed the first compressor with a sidechain from after the plugin of the second channel and the latter with a sidechain from before the delayed plugin of the second channel. No circular references there yet you can't solve the delay issue if both channels have live audio running through them. Its pretty much what I depicted in the image on the bottom left already.

[MarkTarlton]

I disagree - latency with Polar and Neptune is the kind of large latency that's easily compensated for manually, when it comes to rhythmic timing, when they're used as 100% wet inserts.

It's stuff like Saturation Knob, compressors etc. with their few samples of latency, devices that are often used in parallel, and thus cause phasing, that really made the issue of latency compensation apparent. Those issues needed the VMG for fixing - there was no other practical way.

yeah the latency on polar and neptune are not what I am talking about either...it's when you are using an effect like eq, compression, distortion and there is just enough latency to make some serious phase issues.

[avasopht]

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.