Hi all! It's me again and my feature suggestions))))
A topic like this is needed!
And my most current feature suggestion is Delay compensation))))))
"I dream about a Reaktor module, which reports and compensates the delay of any ensemble to the host application .. Otherwise, large number of high-quality algorithms canβt be used in real time without using of third-party plugins that compensate their delay... I believe that the appearance of such a module in the Reaktor is possible."π
feature suggestion: Please add a shortcut key (Ctrl+?) for "snap to grid" option at the settings tab. thanks :)
I still dream about....
NI don't do PDC, Maschine doesn't have it either.
We need them to do it...
I just found out that Reaktor doesn't report PDC to the host system. I've got Komplete 8 (Reaktor 5.9.4), and was about to hit the buy button, but nope. No PDC is a game changer for Reaktor. If however, in the future, they create a way for Reaktor to report PDC would I change my mind about updating to Reaktor via Komplete or a direct buy.
I just still can't believe after all this time and so much complaints on the internet forums about Reaktor and Plugin Compensation reporting that Native Instruments would implement this feature to gain more buyers.
Yes, I truly believe this was a nail in the coffin for Reaktor (Not having Plugin Compensation reporting to the host system or known as PDC in Reaper).
I've got Komplete 8 (Reaktor 5.9.4)
Are you work with Reaktor 5.9.4 or with Reaktor 6.5?
I own Reaktor 5.9.4.
I have not updated or upgraded because I've heard that Reaktor does not report Plugin Delay Compensation (PDC), even in the newest versions!
The very least Reaktor should do is supply an extra two plugins, one that would sit behind Reaktor, and a second after Reaktor to calculate the PDC, then report it!
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 ;)).
All Reaktor has to do is get time now() at the beginning of the plugin and save it as variable, then at the end of the plugin get time now() minus the variable to get the ms for the PDC. It could figure that out no matter what someone creates inside the plugin.
[PLUGIN START]Time now(milliseconds) - [PLUGIN END]Time now(milliseconds) = PDC.
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!
I'll try to dumb this down for you. :)
Reaktor [plugin process starts] (user area) [plugin process ends]
The inital PDC doesn't matter until the calculations are created. The plugin could restart with the new PDC if required by VST3. CLAP however doesn't require a restart for latency changes. It only requires they Plugin stops processing first before making PDC changes.
Reaktor programmer could get the current time before whatever is inside Reaktor created by the user starts. That time becomes variable v1. Let's say v1 is 10:00:00pm where 10 is the hour, 00 minutes, 00 seconds. After everything is processed on the other end the programmer creates a new variable called v2. Let's say that is 10:00:05pm and call it v2. V1 - v2 = 5 seconds. If the sample rate is 96khz. The programmer then multiplies 96 times 5 to get the latency of 480 samples then reports this to the host.
I know in CLAP plugins, the plugin must be at a full stop before reporting any latency change. It is probably similar for VST plugins. I know that the plugin can request the host to restart the plugin.
Yes, there's probably gotta be a intial latency, but it actually doesn't matter until Reaktor does the math for the current latency.
If VST requires to restart the plugin for PDC to work, then so be it. I would rather Reaktor go thru the process of the calculations, save the PDC, and restart itself with the new PDC for that, than not to have any PDC at all.
I've been looking at CLAP because I might just make myself a plugin that would automatically change latency for Reaktor. It would sit under Reaktor by loading it into itself. I could create a VST wrapper to load Reaktor into it and let the plugin run as a CLAP plugin. But, I would rather have Reaktor fix this issue rather than having to work on this myself.
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!
This is insanely overcomplicated every time the discussion comes up π
We just need a primary module that passes latency in samples to the DAW. An event at this module's input would cause a global reset. This seems to me a much simpler request than many of the classic π ones (iteration in core, abstraction etc). The bad rep stuff doesn't make sense to me, sorry -anything can be (and very often is) misused. A bad ensemble can do much worse than passing the wrong latency...
