Folks, newbie question. Found recently this comparison: https://github.com/DISTRHO/Cardinal/blob/main/docs/DIFFERENCES.md
So, i confused only by “Module processing order” cell:
“Same as insertion order” in vcv vs “Based on cable connections” in cardinal.
What meant “Same as insertion order” ? IE the order in which modules are placed in a virtual UI rack affect how signals will works \ routed ? lol Or what.
I would aks the Cardinal developers for a detailled explanation.
From my perspective, there should not be a difference in performance.
If VCV would work on blocks of data (e.g. a block of 64 samples), then the order of processing could make a difference.
Ok thanks. Just, it seemed to me, existence of dependency itself - in how ordering\direction will be placing modules in rack, in terms of modular principle, it’s some nonsense.
(Of course, unless we take into account the emulation of the presence of magnetic fields and other esoteric things lol)
that is about module processing order. as in, for audio processing module A has its audio generated first, then module B, then module C, etc.
VCV Rack, at least on the free/open standalone version, has the concept of “first come, first take”. which usually ends up meaning that, depending on the order of when you added modules, that dictates their audio processing order. the first module you ever added is going to be the first in the chain to be processed, then the 2nd you added etc etc. it is all based on a ever-growing list of loaded modules.
it is not possible to know for sure if this same approach is used in Rack Pro, since it is not open.
this is not about the order in terms of position on the rack, but the order of audio processing.
Most of what @falkTX says is true, and to the point. I do disagree with the conclusion that you can’t know the answer because it isn’t open source. Open or closed, the germane thing would be to measure the performance and compare them.
And for sure it’s totally true that if something isn’t open source, then it isn’t open source.
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.
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
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:
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.
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.
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.
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?
