Reason Rack Plugin Effects 64 sample latency

[spacepluk]

I reported this during the beta but they closed it.

[spacepluk]

I kind of found a "workaround" for this.

It turns out you can send audio from other tracks to the audio input of "Instrument" version of the rack plugin. This way you can use any effects without the additional latency that the "Effects" plugin adds.

It's clunky AF but at least there is a way to get rid of the latency... It would be a lot nicer if the Effects plugin had this fixed though.

[Tiefflieger Rüdiger]

Never tested this but does the instrument plugin really have no latency or does it just not report any latency?

[spacepluk]

The reporting seems accurate as far as I can see. The instrument version only reports latency if you add devices that actually add latency like the softube amps, or a compressor with lookahead. The Effects version always reports a minimum of 64 samples and it's real latency.

[jam-s]

Maybe they did it this way so you can't easily run into feedback loops by accident.

[spacepluk]

I think making everything worse at all times for a corner case like that is a very weird choice.

[jam-s]

It might be better to opt for the safe option than killing studio equipment or the hearing of a user as some added delay at least allows for a little reaction time to possible feedback build-up.

[spacepluk]

I doubt that's the reason for this... but if it is I completely disagree with the solution

[Pepin]

Reason standalone doesn’t exhibit this behavior, so I seriously doubt it’s a “feature”. I’d say it’s either a bug or a necessary compromise due to some implementation decision or host quirk. The only way to know is submitting a support ticket and hoping for an answer.

Other developers like Arturia and u-he have latency for all their effects, even those that don’t require latency as a rule. In u-he’s case, it’s because some hosts like FL studio sometimes feed the plugin non-power-of-two buffer sizes. U-he plugins rely on power of two buffers for certain optimizations from what I underestand. This is the type of “quirk” I’m talking about. There are a lot of host/os combinations with various weird behaviors to account for.

[spacepluk]

Agreed! Sorry I keep repeating myself but also the "instrument" version of the plugin doesn't have this problem (even when I use it as an effect in Pro Tools) so I'm leaning more towards it being a bug or a choice.

I talked to support at one point and the response wasn't very helpful. They closed the ticket with this:

Hi,

Now I've done some digging.
and reason as an effect always gets a little delly after the sound goes through and the smallest bach size that reason sends out is 64.

Tex I you if you add Maximizer and click Look a Ahead it will add 177 Sampels as it needs more time to do the calculation.
And reason as an instrument has no sound passing through it.

Hope they clarify it.

[selig]

Reason standalone doesn’t exhibit this behavior, so I seriously doubt it’s a “feature”. I’d say it’s either a bug or a necessary compromise due to some implementation decision or host quirk. The only way to know is submitting a support ticket and hoping for an answer.

Reason standalone actually does exactly this if you connect an FX send to a Mix Channel instead of the built in FX returns.

Yea, it is not exactly the same (not sure how it could be “the same” in this case), but 100% done for the feedback mitigation reasons mentioned above according to the P-Heads who have commented on it.

[spacepluk]

I would rather have the choice to add a delay if I need feedback mitigation. Forcing this delay in all situations is just wrong in my opinion.

[Pepin]

Reason standalone doesn’t exhibit this behavior, so I seriously doubt it’s a “feature”. I’d say it’s either a bug or a necessary compromise due to some implementation decision or host quirk. The only way to know is submitting a support ticket and hoping for an answer.

Reason standalone actually does exactly this if you connect an FX send to a Mix Channel instead of the built in FX returns.

Yea, it is not exactly the same (not sure how it could be “the same” in this case), but 100% done for the feedback mitigation reasons mentioned above according to the P-Heads who have commented on it.

I hesitate to call that "mitigation" (i.e. for the safety reasons discussed above), because that case seems more like a technical necessity for supporting feedback in Reason's freely routable digital system. If you send the effect back to itself, there will be latency. RS have chosen to introduce that latency once you route to a mix channel, rather than only after you actually enable the feedback send (I assume - haven't personally checked). I think that makes sense since sends can be automated, and you'd likely want the latency consistent throughout any automation.

What feedback exactly would the 64 samples of latency reported by the RRP effects plugin be handling? I don't see how it's analogous to the mixer send example. This is more like every effect in Reason adding an extra 64 samples of latency, regardless of what it's actually doing. Keep in mind the instrument plugin does not exhibit this latency, and it can do pretty much everything the effects plugin can...

I would rather have the choice to add a delay if I need feedback mitigation. Forcing this delay in all situations is just wrong in my opinion.

I guess I don't understand what this "feedback mitigation" being discussed actually means. It all sounds very vague to me.
The latency introduced by feedback loops in Reason is necessary to allow feedback, not prevent it. You can't process input that hasn't yet been written to an output.
AFAIK that's why it works how it does (could be wrong of course).