Possible latency Bug In Reason 10.3

[Blast]

[media][/media]Hey guys I cam across a possible latency bug in Reason 10.3. please see attached video.If it is not a bug I will appreciate an explanation on why this is so. https://www.dropbox.com/s/pkrttcucwuvct ... G.mov?dl=0

[MattiasHG]

It actually makes perfect sense.

I mentioned in the blog post, and it's also explained here: https://help.propellerheads.com/hc/en-u ... what-s-up-

When using that latency checker you're creating a feedback loop. See the cables, you're sending a signal out of a device and back in to itself—meaning feedback. This has always been delayed by 64 samples in Reason, and now it changes depending on your buffer size to improve performance.

Why is it like that? When using instruments and effects normally you render everything in series, all at once. You know that the output of one thing goes to the input of the next and so on, no surprises. Neat. In your case though, the input IS the output of the same device. This is where it gets weird... I'm no programmer, mind you, but think of it kind of like this:

• If we render the input first: oh, shit, the input is silent because we haven't yet rendered the output that is connected to the input
• If we render the output first: oh, shit, it's silent because the input hasn't been rendered yet so nothing's coming in to the device

Because of this, there's a delay. In other words, what you're measuring is completely correct. When there's a feedback loop there is an extra buffer of delay. When there's not, like in a regular mix channel, there's not.

[olive6741]

Excellent explanation, very useful! Thanks. In fact, in my mind, I think like an electronician, a hardware guy. So it 'seems' to me everything is just quite immediate. But in software, batches of some samples processing are needed, and I find this message really highlighting this aspect. Reason looks like hardware, but it's not... (if I'm right in the way I think about it - I hope)

[Blast]

It actually makes perfect sense.

I mentioned in the blog post, and it's also explained here: https://help.propellerheads.com/hc/en-u ... what-s-up-

When using that latency checker you're creating a feedback loop. See the cables, you're sending a signal out of a device and back in to itself—meaning feedback. This has always been delayed by 64 samples in Reason, and now it changes depending on your buffer size to improve performance.

Why is it like that? When using instruments and effects normally you render everything in series, all at once. You know that the output of one thing goes to the input of the next and so on, no surprises. Neat. In your case though, the input IS the output of the same device. This is where it gets weird... I'm no programmer, mind you, but think of it kind of like this:

• If we render the input first: oh, shit, the input is silent because we haven't yet rendered the output that is connected to the input
• If we render the output first: oh, shit, it's silent because the input hasn't been rendered yet so nothing's coming in to the device

Because of this, there's a delay. In other words, what you're measuring is completely correct. When there's a feedback loop there is an extra buffer of delay. When there's not, like in a regular mix channel, there's not.

Ok makes sense now, So routing your sends to a mix channel might be and issue then? thanks @MattiasHG

[MattiasHG]

It actually makes perfect sense.

I mentioned in the blog post, and it's also explained here: https://help.propellerheads.com/hc/en-u ... what-s-up-

When using that latency checker you're creating a feedback loop. See the cables, you're sending a signal out of a device and back in to itself—meaning feedback. This has always been delayed by 64 samples in Reason, and now it changes depending on your buffer size to improve performance.

Why is it like that? When using instruments and effects normally you render everything in series, all at once. You know that the output of one thing goes to the input of the next and so on, no surprises. Neat. In your case though, the input IS the output of the same device. This is where it gets weird... I'm no programmer, mind you, but think of it kind of like this:

• If we render the input first: oh, shit, the input is silent because we haven't yet rendered the output that is connected to the input
• If we render the output first: oh, shit, it's silent because the input hasn't been rendered yet so nothing's coming in to the device

Because of this, there's a delay. In other words, what you're measuring is completely correct. When there's a feedback loop there is an extra buffer of delay. When there's not, like in a regular mix channel, there's not.

Ok makes sense now, So routing your sends to a mix channel might be and issue then? thanks @MattiasHG

Yes, using a mix channel as a return instead of the dedicated returns creates a feedback loop (since you can now send that channel to a send, returning on the same channel etc. etc.)