you are right, it is possible to measure it and get quite valid deductions from it. tbh I really think it will just be the same as the free standalone version, since pretty much everything else works the same way.
1 Like
Since all modules have to be processed every sample anyway, does it matter at all in which order the modules are processed?
Yes, the latency keeps increasing one sample at a time and can lead to phasing issues. Here is a discussion about it Order modules according to cable connections by vitreo12 · Pull Request #410 · DISTRHO/Cardinal · GitHub
2 Likes
So I tested both VCV Rack VST and Cardinale VST inside the same DAW (Bitwig).
Here I show both patches:
VCV Rack
Cardinale
Compairson of Scope outputs
Results:
- The output of the Cardinale Scope shows no latency.
- The output of the VCV Rack Scope shows latency.
But IMO I would stay on VCV Rack because there are far more modules available and the VCV Rack VST allows 16 inputs and 16 outputs from/to the DAW. Cardinale is far more restricted here.
In my opinion, it’s easier to simply keep in mind that each cable produces a latency of 1 sample versus not knowing if latency is compensated or not.
This patch in Cardinale surprisingly produces 1 sample delay, so delay-compensation in Cardinale may not be perfect jet.
At the end, if you introduce a feedback loop, the latency-compensation will be gone (because no software can travel back in time). In most cases, the latency is not audible.
6 Likes
Nice. Compare CPU usage?
That’s not so easy because there are a also lot of differences in the VST-implementations.
I think, a cable with no latency should marked (e.g. striped) to show the user where latency happens and where not.
Another thing to consider is: If there is no feedback loop and I add one, there will be a glitch. Also if there is a feedback loop and I remove it by removing a cable, there will be a glitch.
2 Likes
Oh so your version is latency compensated. That’s very cool!
Thank you guys for elaboration. So, need starts to worry about some phase mess (during complex patches), Including questionable using for rhythmic \ seq related needs. Or not exactly.
This is fixable behavior maybe ? (I mean at dev’s level).
Same big patch, loaded into both, same DAW? do it for 1 or two daws?
if it is the same modules, the differences in performance will be not that much.
I used to have LTO enabled to get the linker optimizing the whole build (because it knows ALL the plugins code during build+link stage), but this causes breakage on some modules as LTO was never officially tested by them anyway 
at the end of the day, I dont think differences in performance are going to be what makes people choose one over the other. cardinal exists as a way to have a proper, self-contained and opensource plugin edition of VCV Rack. the static module list is intentional, pretty much any patch made from Cardinal first release is compatible with the latest one without having to mess with downloading 3rd party modules. Plus we can assume compatibility between not just Linux, macOS and Windows, but also BSD and Web systems (and hopefully soon HaikuOS too)
not being able to fix a software issue I have the knowledge for, being blocked only by “well it is proprietary” is just not something a few of us are no longer happy to live by.
that said, please support VCV if you can, so the ecosystem can keep existing. Cardinal cannot exist without VCV Rack.
7 Likes
Hmmm, hypothetically if VCV Rack would vanish, Cardinal would still be there, and of course, Cardinal could be developed further independently from VCV Rack (in case of latency compensation, this already happened).
Not if you use a host that supports CV ports (LV2 and VST3 only, for now) since then you have 8 audio + 10 CV i/o.
Which DAWs support CV ports?
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.
1 Like
On which hosts this feature is tested so far?