./clap2vcv

Development
1

I never developed an audio plugin (CLAP, VCV, or VST) so I don’t really know what I’m talking about. Given my ignorance, I am probably oversimplifying the process of VCV and CLAP plugin development. Hence the following question.

Is it feasible to imagine a future where we:

  • Setup a build environment
  • Create a collection of .svg files (layers, components, markers, etc.) that represent a rack version of a CLAP plugin that we want to live inside our VCV rack creations.
  • Describe the GUI functionality of graphical items (states of lights, toggles, sliders, rotary things, I/O jacks, etc.) and the graphical components involved.
  • Describe the relationships between these functions (scalar, boolean, enum, etc.) and the CLAP plugin’s parameters and I/Os.
  • Describe the output plugin (slug, name, version, brand, etc.) in a manifest.
  • Execute: clap2vcv -i /path/to/clapplugin.clap -c ./config.json -m ./manifest.json -o "Tadaa!" --install
  • Share this new plugin with my friends who also own that particular CLAP plugin
  • Start vcvrack locally

And experience joy?

2

You could of course write that code. It would amount to being a clap host which didn’t use the gui from the clap. I’ve actually been thinking as well about a clap extension which could let a single clap also have that VCV like information built in. Both would be a bit of work.

The other issue is that refacing a clap or whatnot would result i something kind of like your plugin in host which for some claps is useful but for others you want to factor into multiple modules.

I’ve also been thinking a lot about how I exposed airwindows as a clap where everything was automated (so a single command makes all 300 claps with no intervention) and if that could be useful in rack.

But to answer your question: yes the rack and clap apis would let you do something like what you say, but it may not be what you want for many plugins