RE delay compensation
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.
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 wrote: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.
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 wrote: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.
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.
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 wrote: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.
avasopht wrote: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.
Have you examined how reason currently deals with this scenario?normen wrote:
There is no "next batch" if the device delay is arbitrary. And you're still only talking about the "feedback" situation.
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 wrote: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.
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, ...
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 wrote: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 Audio, LLC
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.selig wrote: Come on then, no more teasing! How are we going to learn if you don't share what you know?
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
- Posts: 906
- Joined: 15 Jan 2015
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 .
but yhea it is strange , i guess it's all developement time that they put in other stuff like RE's .
It does not die , it multiplies !
7.101 and I will upgrade maybe this summer .
7.101 and I will upgrade maybe this summer .
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.CharlyCharlzz wrote: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 .
Give it time.
- Exowildebeest
- Posts: 1553
- Joined: 16 Jan 2015
CharlyCharlzz wrote: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 .
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.avasopht wrote:
We've only had serious latency issues since the introduction of perhaps Polar (or maybe Neptune).
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.
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.Wook wrote: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.
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
- Posts: 1553
- Joined: 16 Jan 2015
Wook wrote: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.
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 wrote:
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
Wook wrote: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.
Heater wrote:
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
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.Exowildebeest wrote:
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.
- CharlyCharlzz
- Posts: 906
- Joined: 15 Jan 2015
CharlyCharlzz wrote: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 .
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.avasopht wrote:
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.
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 .
It does not die , it multiplies !
7.101 and I will upgrade maybe this summer .
7.101 and I will upgrade maybe this summer .
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..avasopht wrote: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, ...
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
- Posts: 796
- Joined: 15 Jan 2015
- Location: Santa Rosa, CA
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.Exowildebeest wrote: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.
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.
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.
-
- Information
-
Who is online
Users browsing this forum: No registered users and 1 guest