Why doesn't VCV expose information from VST SDK ProcessContext?

VCV Rack
1

Questions about how to sync VCV Rack VST with DAW hosts have been asked many times. There are okish solutions, like using PPQN with Clocked to infer BPM, etc.

I wonder why the VCV VST doesn’t take advantage of the plenty of information available from the VST SDK ProcessContext, which includes BPM, time signature, bar position, etc.

I suppose it’s not a technical reason. Actually, it should be quite straightforward to make this data available through a dedicated module. I cannot avoid to mention Cardinal, which makes this one of its “selling points”.

Is it because we want to keep VCV Rack more similar to the hw it simulates? In that case I think it would be a weak reason, otherwise the VST version shouldn’t exist.

I admit this is something that keeps me from using Rack as a VST. I can already sync and route MIDI/Audio through virtual cables outside a DAW…

I would like to hear from the developers, if possible.

3 Likes
2

I understand this works the same with Clocked.

3

@cubistguitar these are the solutions I was mentioning at the beginning. This is no the point of my question.

4

It’s not clear to me what you expect to do with this information if it were exposed.

Working with Rack as a VST is not something that I do much of, so I might well be missing something important. I’m just not sure what kind of module would make use of this information when running in the VST, given that the same information is not available to the module outside of the VST.

5

One important aspect is native time sync and start/stop with the DAW. This is possible using midi input but not reliable. It’s better with cv sync or using Pam Sync as noted above, but having a native DAW Sync module is the more ideal solution.

I agree this is a missing piece in the VST which is otherwise great.

A continuous sync from the DAW also solves an issue when VSTs are hosted in the VST Host module. Because these don’t sync until the clock starts, this leads to sound artifacts when BPM changes.

1 Like
6

@carbon14 I think @auxmux expressed the reasons perfectly. Specific modules, or specific modes could be implemented in existing modules, to take advantage of this reach information.

Having this informationreadily available, without having to adopt strategms (which often are not enough for perfect syncing) is one of the advtanges provided by VST.

Beyond BPM, one of the most important things to me are beats and bars alignment.

3 Likes
7

No idea, but I use both VCV Pro and Cardinal and I think Cardinal is actually easier to use with DAW. Would be good if VCV used the same approach.

8

For me the use of a custom module for handling host/daw-based tempo information was one of the basics and very first things to do when developing a Rack-based audio plugin.

Every CLAP/VST/AU/LV2 plugin that wants to sync with the host uses the host time information to do it, it is part of the spec for a reason. Different plugin formats handle it slightly differently, but the idea is the same - sample-accurate sync of play status, BBT/PPQN, timeline position and time signature. Converting these to clock pulses to be used by Rack modules is simple enough, we basically just need to keep track of play status and trigger a pulse everytime we see a new bar and beat.

There is some oddity with loading patches that use the custom host time module in standalone, as there is nothing to drive the time on that mode. But on that case why not fake it? If there was a module that always provided a reliable clock, that might be very welcome, no? it could even allow the user to change tempo if running standalone or if the host + plugin format also allow such changes.

On a more personal take, it is hard to be excited about the Rack plugin version. While the standalone is open-source and as such allows us to build and run modified versions, the plugin version is not. So even when knowing how to add / change / fix the code to allow new things (like integrated host time), there is nothing we can do about it. There is also the case of ARM builds, Linux runs quite nicely now on mac M1 machines with Asahi and the Raspberry Pi 5 is looking quite nice, but it is still not officially supported and at the pace things are going I am not sure it will ever be… So yeah I will keep doing my thing with Cardinal.

4 Likes
9

Most of that is true, but what do you find wrong with rack’s ARM support?

10

from what I understood it is only for macOS, and quite some modules are still not ready for it which leads users to ignore it and still rely on the x64 version.

Linux has been running on ARM for a very long time now, Windows is slowly becoming relevant there too. This very slow pace of changes leads me to think VCV is always going to be playing catchup.

1 Like
11

That’s true for every software in existence. There is no automatic way this happens (until AI has progressed significantly farther). It requires human beings taking the time to do the work, and each target brings unique issues that must be worked through and supported. Each additional target comes with a cost. Consider that Rack is still free. Rack is already far ahead of most software in the range of platforms it supports.

So, a judgment has to be made on the potential reach for an additional platform. While Linux may be on ARM, the devices targeting ARM are currently mostly targeting the lower end of performance, so not great candidates for running Rack (although this is changing). When there are large numbers and the performance is sufficient, then it becomes a viable target.

2 Likes
12

Ah,ok.

13

I know I “should” know this, but is it easy/possible for a VCV plugins to access this host context? Do you know of any open source plugins that do this that I could peek at?

14

@Squinky I’m not sure what you mean but I suppose it should be provided by a core module, similar to Cardinal’s Host time module and a clock synced to he host.

I guess the VST Rack VST plugin can easily provide context information to such a core module

15

Well, it’s not easy by any means, but it’s possible.

16

I haven’t done a lot of investigation with Rack as a VST. When I have used it, the tightest timing seems to be to send it a steady stream of notes so that you can use the Gate of the MIDI-CV device as a clock.

It also appears that this thread is VERY VST-centric. You can’t simply ‘expose the VST timing context’ in Rack. You’d have to write a Rack::HostTiming class, and implement a subclass for every supported plugin format.

I imagine that CLAP and AU also pass clock/tempo/song position to plugins, but it might not be 100% straightforward to present an interface that behaves the same for each plugin format.

For that matter the differences between the VST2 and VST3 API are significant enough to require a fair amout of coding changes.

17

And really, if you need to know how someone implements using host clock in a plugin, why not go here?

EDIT: When I looked there, I found that Surge XT uses JUCE, which is a cross-platform library. I imagine JUCE exposes the host tempo/song position/bpm and they just leverage that.

18

Yes, Juce does. It does not seem simple, but it clearly is possible.

19

You know the internals of Rack much more then me, and I don’t know for sure how Rack VST plugin is implemented because it’s closed source.

I only know that the PluginContext information is widely used by plugins, and it’s implemented by all the audio plugin frameworks I know: JUCE, iPlug2, DISTHRO DSP.

Every audio/midi plugin thst needs to sync with the host uses it (delays, sequencers, modulators, etc.).

I don’t know if the implementation of a core module in Rack VST like Cardinal Host time requires such a big refactoring. Cardinal does it without needing VCV Rack modules to be changed in any way. I guess @falkTX can provide more info on this.

PS: CLAP, AU, LV2 provide similar information, so my thoughts are not really limited to VST

20

For Cardinal in specific, I override the rack::Context to provide the extra information provided by the host. See https://github.com/DISTRHO/Cardinal/blob/main/plugins/Cardinal/src/plugincontext.hpp#L57

there is a lot of stuff in there, but the important are these bits:

    int32_t bar, beat, beatsPerBar, beatType;
    uint64_t frame;
    double barStartTick, beatsPerMinute;
    double tick, tickClock, ticksPerBeat, ticksPerClock, ticksPerFrame;

this info is retrieved directly from the host where Cardinal runs on, of course with some variance between the different plugin formats.

then as you noticed on the Host Time module, this information is used to drive the CV signals.

and that is it.

2 Likes