Feature request: delay compensation
Comments
-
We just need a primary module that passes latency in samples to the DAW.
What's about the Hardware Module?
0 -
Absolutely correct.
It is not difficult for me to calculate the amount of delay in the ensemble I am designing, and then manually specify this delay in the hypothetical reaktor module that will report this delay to the host. However, if in my ensemble the delay will dynamically change, then at the design stage I have to take this into account and specify in the hypothetical reaktor module the maximum delay of my ensemble, and in those places of the ensemble where the delay may change to a lower side I have to make additional delay at the design stage, so that the amount of delay at the output of this module will not change...All I need is a module in the reaktor where I can manually enter the delay value, which will be reported to the host .
0 -
Overall, the programmers are smart enough to program Reaktor. It should not be hard for them to figure out how to incorporate PDC for Reaktor [Even if you must restart Reaktor for the new PDC to take effect, for most of us, that would be a major plus!]
0 -
It should not be hard for them to figure out how to incorporate PDC for Reaktor
Do you know someone of them or the language in witch Reaktor is coded? What if … some other functions become issues.
0 -
I would be surprised if it wasn't coded in language c or c++. I on the other hand program in a long forgotten language Delphi.
0 -
The bad rep would be an 'excuse', but still a valid one IMO in the context of modern internet discourse.
As far as a module that causes a reset when you send to it. I'm still not convinced that this would necessarily be a trivial thing to implement. It depends on how Reaktor's code works, and we don't know that.
We just need a primary module that passes latency in samples to the DAW.
Well, that really does sound simple ;)
How would you implement that?
For me when I think through it, it seems like a non-trivial implementation that may require changes to Reaktor's initialisation and reset procedures. It would require significant development and QC resources. Particularly from the POV of testing with multiple different DAW's. Not sure the existing beta process would be adequate...
0 -
Well, we don't know the details of course. Sending a latency change is not that complicated though. Here's the sequence for VST3. You just tell the host "I need to change latency". The host will stop your process and start it again, at which point it will ask for the new latency. Any plugin must implement setProcessing, setActive and getLatencySamples, so that's done already. You just need a variable to store the latency, and a restartComponent call to notify the change.
Switches already cause global resets, and they can be triggered programmatically. So... I think there's not much in this feature that's not already dealt with.
1 -
Latency could be measured by Reaktor just before reset. The measured latency would be stored somewhere. If it is not possible in already running plugin, it may be stored for example in temporary file, or in registry.
0 -
Is the plugin allowed to decide do do different things (like choose some 'soft' reset variant) when the host restarts it after a restart request for PDC, or is the restart basically like a reload with full reinitialization, which would - I assume - be a GRE?
0 -
It's not a reload. Reloads are avoided, because plugins may have state that's not saved in the host chunk, like Reaktor ensembles. The host actually does nothing to the plugin state, they're all callbacks, it's up to the plugin what to do with them. There's a number of changes (latency, sample rate, channel configuration, etc) that require to stop processing audio, so when the plugin is (re)activated it needs to check all those things and set itself up. While the plugin is inactive there are no calls to the process callback, so there's always a hiccup. The host doesn't force a GRE, but it's the reasonable thing to do, because the continuity of the audio stream is broken.
2 -
That makes sense, and should make it easier to add PDC to Reaktor, but I think GRE would not work.
Ok, back to devil's advocate mode:
User code in Reaktor cant talk to external stuff like host etc., so the only way to handle it would be code that calculates to PDC value and sends it to a hypothetical PDC module which does the rest. The problem is that a GRE would cause the user calculation code to run, and the PDC send to happen each time there is a GRE, so a 'simple' implementation you would cause a nasty loop... Some alternative form of reset that makes it easy or possible to avoid that problem would be required... or some other clever way to prevent that problem, without causing other problems.
The issue is that NI would be putting enough power in the user/builders hands to potentially cause crashes and lockups if they got that wrong... which is definitely something they are against policy wise.
That's why I was talking about possible changes to initialisation being required - to avoid that kind of potential issue...
Not requiring a complete reset should make it viable... but not as trivial as many seem to believe.
I imagine that if this was super easy to implement, and is something NI want to have in Reaktor, it would have been done long ago (maybe around the time they gave us ezfft library?). So either it's non trivial, or they don't want it, or both...
2 -
It's actually not that hard to solve.
An event at this module's input would cause a global reset.
That's a simplification. An event at the module's input doesn't directly cause a GRE. The GRE is caused by the host reactivating the plugin. I think the simplest implementation would be timer based, to avoid issues with duplicate events. There's only one latency module per ensemble. It holds an input value and an output value. At display rate, and at the end of a GRE, if input != output, then output = input, and send a latency change (restartComponent with kLatencyChanged for VST3, setInitialDelay and the audioMasterCallback with audioMasterIOChanged for VST2). The host waits for the current process callback to finish, then deactivates and reactivates the plugin. A GRE happens, which recomputes latency. If the value hasn't changed again, the module does nothing. Otherwise there's a mistake, so we reject the change and show an error. The error goes away after the next GRE. In pseudocode:
2 -
That seems fine, but...
There is no absolute guarantee that every host will update all its graphs within a display update... (they all should by orders of magnitude... but there is no guarantee!) so shitloads of testing would be required with lots of hosts, and that's expensive, and not something you can do with a normal beta program...
Also seems that there needs to be a difference between the GRE, and the plugin startup initialisation process... or it will be broken. For your idea to work the output and input values need to be persistent across GREs, so that the equality check is valid. But they must not be persistent across sessions, or else latency value will not always be sent at session start... so you need a special case... if that's already a thing for the Reaktor plugin, then it's easy to add this into the existing system, if it's not already there, then you have a bigger workload to implement the feature, because you have to start messing with initialisation code - which is opening a can of worms in a Reaktor context!
Is there a way to ask the host what the plugin's current latency setting is? - that would make it much easier.
...anyway, it's definitely doable, and desirable, but everything has a cost. It's a shame this wasn't implemented a looong time ago when the codebase wasn't so old and brittle, and the folk who wrote it were still working on it... :(
1 -
There is no absolute guarantee that every host will update all its graphs within a display update
When I say "at display rate", I mean on the message thread timer that Reaktor is already using for UI updates, and surely many other checks. This is the simplest place to place this check, because the notification must be sent from the message thread, so it cannot be finely accurate. Like display updates, it would be done roughly at 25 Hz, unless the message thread is too busy, and that's alright.
For your idea to work the output and input values need to be persistent across GREs, so that the equality check is valid. But they must not be persistent across sessions, or else latency value will not always be sent at session start
Is there a way to ask the host what the plugin's current latency setting is?
The UI module is just an interface, the values are persistent for an ensemble's lifetime, and they're not stored in host chunks. Every time an ensemble is loaded, they're set to zero and an initial notification is sent. At the first GRE, an ensemble with a latency module can set a new input value. If there's no latency module, they stay at zero. If the module is removed, they're set to zero again. getLatencySamples is a pure virtual function in VST3, so it must be implemented, and initialDelay is a field in VST2, so it's already there. They both return / store zero now.
I don't say "I'm completely sure this is a terribly simple request" because I don't like to speak in those terms, but I am. This is simpler than high-DPI support, much simpler than any Core-related request, way simpler than a vector-based UI or even a merely scalable one. Among the many indications that the company has zero interest in developing this software, this is top five. If this can't be done, nothing else can.
2 -
Among the many indications that the company has zero interest in developing this software, this is top five. If this can't be done, nothing else can.
I have a very similar feeling
1
Categories
- All Categories
- 21 Welcome
- 2.1K Hangout
- 86 NI News
- 1.5K Tech Talks
- 2.6K Native Access
- 14.2K Komplete
- 1.4K Komplete General
- 3.1K Komplete Kontrol
- 4K Kontakt
- 3.6K Reaktor
- 342 Battery 4
- 637 Guitar Rig & FX
- 328 Massive X & Synths
- 792 Other Software & Hardware
- 4.2K Maschine
- 5.2K Traktor
- 4.9K Traktor Software & Hardware
- Check out everything you can do
- Create an account
- See member benefits
- Answer questions
- Ask the community
- See product news
- Connect with creators