@chaircrusher @Squinky just to clarify, I’m not expecting Rack to provide the host context info to any module. My proposal is that Rack provides a module with CV outputs driven by the host context values, like Cardinal Host time does (sorry for repeating this again…)
But isn’t part of the issue is Cardinal is for the most part a fixed environment with known components that do not change weekly. VCV has 3000 modules many joining in the last several weeks, wouldn’t processes within each one have to accounted for in this process module.
I’m not following you. Why should other modules affect or be affected by that?
Rack pro implements a closed source plugin. Couldn’t it also implement e core module with access to a private context / api, if fhat matters?
Other modules should only plug into its CV outputs.
But I assume this sort of thing would require a new build for each module with many many various authors. Getting that to happen just to meet Apple OS requirements has been a long term project that isn’t even complete. I assume this would open a similar can of worms.
That is not correct. This would not require changes to other modules. This is about creating a new module to receive transport and bpm info from a DAW. The info would be converted to CV in that module that existing modules could use. Check out Cardinal VST for details.
1 Like
argh! cardinal does allow pluins access to that info, also. That’s what he said, above. So they make a module, too.
It would be very unlike VCV to make some magic API that only they could use. So if they were to do this, they would probably add/enhance an API to that any module could do this. would they make some core timing module, too? Possibly.
It would not break any existing plugins to do this.
So - if you want to use a new VCV timing module, cool. I’d prefer to use Improptu clock. There’s plenty of room here for both. There’s no magic here, just features in VCV that don’t currently exist.
2 Likes
The great thing about Impromptu Clocked and other modules is that they can follow a DAW sync module, so yes both are possible. That’s exactly how the DAW sync modules in Cardinal and Mirack work.
I clock divide all the things from there anyhow, hehe.
I meant that if you clock of choice (say Impromptu) had access to the daw info directly you would not need a “vcv clock” module.
1 Like
Whatever the solution, and there are plenty of them, I go back to my original question: why isn’t this impelemented, given that the main feature of the paid version of Rack is the integration with DAWs?
I would like to hear @Vortico 
4 Likes
Well, it is just a feature.
My 2 cents, my guess:
Let’s assume the VCV Rack plugin exposes all that information from the VST 3 ProcessContext, and I make a patch that uses these information.
What would happen if I run this patch in VCV Rack standalone where those information is not present?
I think it’s all about compatibility between VCV standalone and VCV VST plugin.
As was said before: for the standalone a mocking of this behavior is totally reasonable. The same time module could produce its own transport in standalone and the rest of the patch would be none the wiser.
Yup, exactly, the new module could follow DAW transport in VST or generate it’s own clock in standalone.
If you switch from vst to standalone, audio devices also change, so not like there’s hundred percent compatibility anyhow.
no, unlike the others I don’t imagine that VCV would provide a master timing reference. They have never seemed very interested in doing that.