Feature request: delay compensation

feature suggestion: Please add a shortcut key (Ctrl+?) for "snap to grid" option at the settings tab. thanks :)

Are you work with Reaktor 5.9.4 or with Reaktor 6.5?

Stop catastrophising lol

Its annoying that this feature is missing, but it's minor compared to some of the other long wanted features, and even those are not show stoppers.

Apart from the obvious development costs associated with any new features, adding PDC is not such a simple task for Reaktor.

In most plugins, it's relatively trivial from a conceptual point of view, just calculate the delay, and report it to the host.

Problem 1:

In Reaktor, there is no way for Reaktor, or the Reaktor Developers to know or calculate the delay of some particular plugin from some arbitrary builder. So what about a module for builders to set up and report the delay?

If they give us a module for reporting, and half of the builders - who are mostly enthusiastic amateurs - get it wrong, then Reaktor just gets a bad rep as an untrustworthy plugin. At least with no reporting, it's clearly up to the DAW user to use a workaround in their DAW.

Problem 2:

IIRC, there is an issue related to when the plugin is supposed to report the delay to the host.

I think the problem is that the ensemble is running in Reaktor which is running in the DAW and each layer requires initialisation in the correct order. The DAW/Reaktor initialisation needs to happen before the Reaktor/Ensemble initialisation can happen, the PDC value can't be calculated/retrieved from some System module until after Reaktor/Ensemble initialisation has completed, but reporting of PDC must happen during the DAW/Reaktor initialistion - something like that anyway.

EDIT: not sure it's as bad as that, but it does need a plugin restart - so it depends how that is handled by Reaktor as a plugin and whether that whole process would need a rewrite. It's also problematic as changing the latency causes the DAW to rebuilt its signal graph (or something), so an ensemble that does it a lot (due to a but, or incompetence, or malevolence, or whatever) could cause the whole project to dropout and become glitchy and unstable... again, a bad rep for Reaktor! /EDIT

If that's the case (maybe not - maybe VST3 has a better system?), it's hard to see how it would be possible in Reaktor without at least a rewrite of the initialisation process, and maybe a redesign of how Reaktor works in terms of how Primary and Core work as interpreter and compiler, which would be a massive change, and likely break backwards compatibility with the library.

It would certainly be good to get some word from the devs on whether this is possible/feasible/likely. I'd imagine possible but not feasible or likely. Just so we know the situation.

Until then, builders should report visually what the latency of their ensembles is, that way, it would be easier to set up some external compensation. e.g. I have a convolution delay in the UL, and it reports it's latency on the front panel (probably wrong though ;)).

When does it have to do this?

how will that fit in with the Reaktor initialisation process?

what are [PLUGIN START] and [PLUGIN END]?

Also, I'm not quite sure how any of that helps. Remember that the latency of Reaktor is not the same thing as the latency of some process running inside Reaktor it's really not possible for Reaktor to 'guess' how much latency is being introduced by some Primary or core process which is literally just a bunch of arithmetic and memory operations.

The problem here is not calculating the PDC, that is something for the builders. The problem is when the PDC has to be reported to the host, and how that fits in with the initialisation process of the Reaktor plugin...

e.g. if the plugin needs to report the PDC during the reset initialisation required by the host (does it?), but the Reaktor code needs to be fully initialised so it can calculate the required compensation (it often would), then there is an intractable problem.

This is all conjecture, but its important not to underestimate the complexity of this sort of seemingly simple concept, particularly in the context of Reaktor. You have something that is a plugin, but also simultaneously an interpreter, and a compiler. Initialisation is not a simple process!

According to the Steinberg docs, VST plugins must request restart when reporting PDC or change in PDC.

The problem that may exist (WE can't know for sure without access to Reaktor source code, or confirmation from devs), is when in this restart process the PDC needs to be correctly reported. If this must be done before Reaktor is able to run all it's initialisation layers and then allow user code to calculate latency, then PDC reporting will not be possible.

Reaktor has a multiple pass initialisation process. It _may_ be possible for one of those passes to run user code to calculate PDC, but it's not obvious.

--------------------------------------------------------------------------

Builders in Reaktor don't have direct access to the VST process buffers, or the system clock. And the top level of the Reaktor application can't know about latency that may or may not be generated by some core or primary code.

All that stuff about timestamps will not help. It makes me think you don't understand the problem.

How do timestamps help the Reaktor plugin know that some user code is using e.g. fft based processes that could be causing some arbitrary latency? The process starts generating output samples immediately, there is latency before 'meaningful' samples appear, but Reaktor has no way to tell the difference. The only way for PDC to work in this context is for the builder to write code that calculates the delay. It can't be automatically 'measured' by some external timing process, but as I've explained, it's not obvious whether this would even be possible without significant changes to Reaktor.

It could potentially work by having a module in Reaktor that builders can 'send' latency values to, but that would require the code to be up and running inside the plugin early enough in the initialisation process. Is this technically possible without major changes? I don't know, and neither do you!

One thing I do know, it has nothing to do with CLAP!