Separate names with a comma.
Discussion in 'Feature Suggestions' started by Z Gabr, Jan 6, 2020.
How do you know? May be can help to make it faster...
It may seem that way, but it's really not like that. This assumes Reaktor team is looking into these forums often, which might or might not be the case.
I'm rather sure this is not happening "faster" or "any time soon", considering greatest priorities for NI currently are VST3 and Apple Silicon support. Both heavy undertakings.
Programmers do not decide, what has what priority. They may have opinion, managers may have different opinion....
Good example is support of Jam for Maschine+. Programmers were eager to implement the support, there was even proof of concept. But probably managers decided - no support. Jam is dead.
And continuous demand of users of this forum made managers to change their mind. So, somebody sometimes analyzes forums. It would be silly not to....
Well, faster or any time soon are two different things. Faster may mean few months sooner or at all. No question Apple Silicon has the highest priority. VST3 is also important, but Delay compensation may be part of the task....
I do not know, how difficult it is to implement delay compensation in Reaktor. There may be many obstacles, I guess..
Steinberg stated the VST3 interface expands VST instruments by adding the ability to create audio input busses. As a result, audio data can be routed to an VST3 instrument. A synthesizer which has a built-in e.g. vocoder effect is able to process audio data coming in from other sources as well.
I can see this being an excellent update. Much more important than fixing something the free voxengo plugin already fixed. Furthermore I strongly suspect VST3 will incorporate latency reporting. Considering Version 3 is designed to interact with other plugins it is absolutely necessary to report latency in order to sync up with other vst3 plugins.
Speaking to the guys that want it fixed. What's the big deal with Voxengo plugin, I thought it was cable of latency corrections up to 10000 samples or something. If this is not enough tell Voxengo. They could update something that dippy, there's nothing to it. The daw handles the latency it's given. Seriously doubt it's a problem unless some moron writes a plugin with a few days of latency just to mess with the daw. lol
If they do VST3 and do not include Delay compensation they will get a ton off feedback requesting a fix. I doubt the management will oppose it and it's also the reason nothing will ever be done about it in vst2. Does you DAW support VST3?
The thing is, that if plugin does not report the latency, while it should, one has to solve this deficiency by hand. If it makes problems. It is more work, it is not errorprone and latency might change with plugin settings. So, more work for user, more possible erorneous settings.
It is like having a car with speedometer that shows wrong values. Yes, one may add certain value if going to east, another going to west, yet another going to south, ... And absolutely different if, there is just driver, or one, two, three, ... passangers. It is simple and solvable. One day, there may be a new car, that will report the speed correctly. Hopefully.
Or someone fixes the current car speedometer.
I'm curious if Nuendo derives it's own latency value for a plugin, it's possible they do. Here is a link to a 60 day trial. After all , these guys may have invented VST plugins. I wouldn't doubt it. https://new.steinberg.net/nuendo/trial/ I'm sure this isn't cheap , 35 cents like MAD magazine.
But VST2 should also report latency.... And it does. But in case of Reaktor the wrong value 0. ;-)
Yes, I know, but if VST3 comes out maybe you'll never use VST2 ever again. I'm am not sure, maybe someone else can answer that.
If VST3 comes any soon, than it is solution. But, I guess, the problém is not how to report latency, but how to find out how much it is. Otherwise Reaktor would already report it.
That's very easy, Simply make a short 100 ms noise burst on two inderpendent channels. Then use reaktor as a plugin on one track only. Make sure there is no added delay module in the reaktor plugin, just filters and what not but no extra time delay for echo or whatever.
Now you are all set to find the latency.
How would you continue to find the answer? Track freezing, playing the two tracks and recording them at the same time, exporting the two tracks to a short file and re importing them. Several ways to see a delay from the latency.
Once you see the time delay between the two tracks zoom in to the sample level and count how many samples of delay between the two tracks and there is your answer. The easiest of them all is the track freezing as it does it all in one step. Most daws freeze a track by converting the output into a wave file so any latency is included in the wave file. It's a very simple method, freeze both tracks too in case the daw has a problem time aligning the wave file after a freeze. Does you daw let you make a noise burst ? If not use the noise in reaktor and make your own. Time align it to start at 0 and save it as a wave file in your daw. Once saved you can use it anytime. Also verify the saved burst remains in time when you reload it. It wouldn't surprise me to see it shift in time by simply saving it then reloading it. Some Daw's are not perfect either and not mention the side effects of the operating system itself. This is why every track needs a short tone burst 20db down and 5 milliseconds long at the beginning of each track so that can be time aligned in the end.
Only the builder can know how much latency their algorithm will cause at some particular sample rate, and with some particular panel settings configuration. It will have to be calculated by the ensemble/instrument. Which is not trivial to get right - but probably not so bad for anyone who understands enough to develop code that needs compensation...
That is part of the problem I suppose - better to have no compensation than to have some ensembles report it accurately, and other not - then Reaktor just starts to feel buggy.
I think it's also historical. Reaktor is very old, and for many years there was no core layer, so no way for users to implement complex DSP like FFT based algorithms - the sort of thing where latency reporting is important. So no need for correct reporting to the DAW.
So now that we can do cool FFT stuff, we want this feature, but NI must prioritise their resource. And they also must balance the concept of a development environment that's supposed to be for everyone with the idea of adding 'advanced' features that have a pretty limited appeal - how many users are there who have built an instrument in Reaktor that needs Latency reporting, vs how many users have not?
It would be something of a difficult sell at a developer meeting with managers - some fancy new feature with great marketing potential... or... Latency reporting? Yay, we know how much everyone loves latency after all
However, we can keep asking
It doesn't seem that difficult though. As you say, only the builder knows how much latency their algorithm will cause. In some cases (especially when IIR are used to replace something commonly done with FIR) there's not even an absolute answer. We only need an output module with a single input in samples. Reaktor doesn't even have to do anything with it, other than inform the host.
Well, if the resposibility would be on patch developer, and NI would only report the thing. That should not be that difficult. If you ask for this, than I understand, you are not extremely patient. I thought that you want automatic calculation done somehow by Reaktor, which would be tricky to implement.....
Here comes importance of frequently demanding that feature. ;-)
To make it right, Reaktor would have to re-calculate and re-report the latency after every change, no? Let’s take a Blocks patch: what would happen after adding and patching a FFT based module?
It would report new latency value. If the developer decides so.... Would be better, if Reaktor would calculate it somehow itself..... But, still better if that is responsibility of designer, than no way to report it. Some patches would report it some no.
I don't think it's a good idea to make Reaktor calculate it. Apart from being very complicated, in many cases it's just not possible, so Reaktor would make a wrong guess.