Is there a chance the latency compensation could get ported back to Rack (Pro and free)?
No, VCV does not accept pull requests and code contributions even when all ownership is relinquished.
I guess that makes sense in most cases, since those could be cause for bugs and a lot of extra work, but maybe they could look at it and implement it themselves… let’s hope that might happen.
No DAWs that I know support CV ports, this is mostly a thing for modular plugin hosts. So with these CV ports we can have CV-enabled plugins sending signals to each other.
On the IO, in my view it is preferable to run multiple plugin instances instead of a single monolitithic one. When loaded in hosts that can do multi-core processing per track/mixer-strip, we get advantages of better CPU usage automatically.
On which hosts this feature is tested so far?
Doesn’t one of the newer plugin types support multi threading on a single instance? I know most don’t, as you say.
I have my own KXStudio : Applications : Carla that supports audio, midi and cv ports. There is also Ingen and synthpod.
Modular tools based on JUCE (like Kush Element) do not support CV because JUCE itself does not support it (not just for the audio-node graph side, but at all)

Doesn’t one of the newer plugin types support multi threading on a single instance? I know most don’t, as you say.
plugin type? some plugin formats have the concept of “workers” but they tend to be used for non-realtime tasks scheduled in time with the audio (so for example loading a file and doing an atomic pointer swap after it finishes loading)
CLAP also has a concept of “thread pool”, but I am not familiar with how that works.
Yeah, I was thinking of the CLAP thread pool, but I also know nothing about it.

I have my own KXStudio : Applications : Carla that supports audio, midi and cv ports. There is also Ingen and synthpod.
I tried Ardour but it does not supprot CV ports.
So won’t think latency cause problems when you’re doing FM stuff?
I guess that you could just select the corrispondent “hardware output” from the routing button on track control panel. tomorrow I’ll take a look because today I don’t have the ES-9 at home
@Ahornberg as well
In the environments that I use that are sort of like this (Max/MSP, Eventide VSIG) this does matter, and they both have ways to minimize the issue.
Eventide allows you to renumber the modules to be in an efficient order.
Max/MSP build it’s own processing order tree, and has positional rules that allow the user to control this to some extent.
(I know this is an older thread)
I don’t even need to. everything works out of the box, ES-9, Reaper7 on Win10. Just use the “audio” inputs instead of the “CV inputs” on the module. on the Raspberry Pi I have to use an “external hardware output” from the routing window, but, again, it works
Since this is not clearly communicated it is often overlooked, that Cardinal uses the ordering of modules to apply latency compensation.
This means you don’t have 1 sample of delay for each cable in Cardinal, and signals going different routes with different amount of modules/cables arrive at exactly the same time and you don’t have to compensate any delays for perfect synchronisation of both signals.
It also means you always have just 1 sample of delay in a feedback loop, no matter how long it is.
So it’s a bit more realtime and closer to how a real analog system might work, which can be very convenient, depending on what you want to do.
I was hoping, this technology would be applied to VCV Rack, too, but I guess it’s very unlikely now with the option of multiple inputs on one port.
Also, Cardinal has the AIDA-X module, which is a very nice AI based distortion - would be nice if someone could port that one to VCV Rack, too.

Modular tools based on JUCE (like Kush Element ) do not support CV because JUCE itself does not support it
Actually Kushview Element does support LV2 CV ports since this year. They are not using stock JUCE for their LV2 hosting.