VCV Library alpha

I am running the private alpha version of the future VCV Library at

When this is released, you will be able to add/purchase VCV Rack plugins from the website. The current VCV Library web app at will redirect to this site. After Rack v2 is released, you will be able to add individual free modules if you don’t want the entire plugin, and when rackdrm.hpp is made available to commercial plugin developers, you will be able to purchase individual modules for lower prices than the entire plugin, and/or add trial plugins to your VCV account, depending on the plugin developers’ business model.

Please do not post links to this on the web. I will archive (hide) this thread in an hour or two, but I am giving anyone that sees this early access for testing.


so far it seems to work,
but I miss an option to go back
or choose another search after I selected a module

like here:

I can only hit the page title “VCV Library.” which is not that obvious :wink:

Browser back button ?

There are too many routes to the module to breadcrumb it I think.

I guess the interface is not finished yet though and there could be a menu option for a new search.

very interesting!

Will there be a way to screenshot modules without light states and other visual glitches*, In my opinion, for the server API, it would look more presentable if screenshots show as if they were in the Rack.

Also is there any plan to include tooltips or short descriptions of what each component would likely do when browsing the server i.e. hover Fundamental LFO rate knob, “Controls speed of LFO”

*some cases where there is extra things outside the page border in an svg file others are unknown bugs (mscHack)

Is a single value dropdown list the way it’ll ultimately be presented? From a final design perspective, I think some kind of multi-select capabilities would be the way to go. So I could check a box for VCO, and VCF (would act as an “or” condition) then further refine by selecting a manufacturer (which would be an “and” condition).

From a feature perspective, from adding individual modules to being able to demo, or purchase individual modules, this sounds exciting. Good stuff!

1 Like

It would be nice to have a results per page perhaps? Or for it to auto-generate while scrolling.

I’m not sure I understand the problem here. Clicking “VCV Library” seems obvious to me.

I imagine the “individual module” commercial option will be available for only a handful of vendors. This is too fine-grained for most plugins.

The details of module screenshots are a Rack thing, not a VCV Library thing. Open a GitHub feature request to discuss technical changes to Rack.

No, I have no plans. How would this be possible? I don’t know.

Why would you want an “or” condition for tags? I can’t think of a single use case. Just make two searches. You can already narrow results when selecting both a tag and brand.

What you mean by “a results per page”? I decided against infinite scrolling as it requires dynamically building the page, which is bad for SEO, accessibility, low-RAM devices, and increases complexity for no real advantage.

I have fixed an issue where plugins without a "brand" property are incorrectly assigned "author" as the brand name instead of the correct "name" property.

1 Like

RE: “results per page” example:
I was thinking 50, 100, All. Could help also, if you want to limit the selections for low RAM. Some other weird and wonderful examples on that page :wink:

Regarding the “or” thing, I was thinking of the use-case of “I want to use something as a VCO but maybe not just strict VCOs” like maybe using an LFO as a VCO (“show me all VCOs or LFOs”). But as I think through this in a practical sense, yeah, an and condition makes more sense. “Show me all VCO’s AND polyphonic.” I’d use that much more frequently.

Regarding adding descriptions of the modules to a details page, I think that’s a must for a commercial site IMO. My understanding of what you’re looking to eventually do with this is that it won’t just be a library, it will also be a plugin manager and [perhaps most importantly] a store front. If you think of it that way, then having some kind of description of what you’re about to demo/buy is practically a must-have feature.

So how could descriptions be managed? I’m imagining a system where the developers own the text. Maybe there’s an XML tag in the module itself that allows for a detailed description that gets picked up by the website, or maybe there’s some kind of form that would allow developers to upload some text as part of the submission process. They should be able to write their own copy and “sell” (in both literal and figurative senses) their plugins as they see fit by including some flashy copy - or none at all if they choose. Out of curiosity, I just checked out the Cherry Audio store to see how they handle it, and they do indeed have text for each module after you click on it in the store.

Lastly, I’m not sure if you’d want to include a user-generated rating system, but I think end-users would love the ability to leave reviews/rate individual modules and/or bundles. I could see users wanting to sort or filter on ratings, and also price (“show me free, 4+ star filters, sort by rating high to low”). While I could see some developers cringing at the thought, I’m thinking of it entirely as an end-user. “I want to buy a really good filter - but there are so many - oh these Vult filters have a lot of really great reviews - bought!” It could really help with making the site user-friendly and customer-focused.

Sorry, I’m imaging the future-state as a store-front (on top of the plugin manager/explorer) so I’m thinking of useful/common store-front features.


Yes, I just wanted you to get this conclusion on your own.
If we can fit multiple selection into the design of the search form, we’ll add it.

What VCV Library is is an unbiased index of Rack plugins, like a public library.
What it is not is a marketing page for plugins and modules. The plugin marketing page is the "pluginUrl" property of the plugin manifest. An example is, which is linked from the module/plugin page, in this case

No, I am not changing this distinction. Marketing your plugin is the responsibility of you (as the plugin developer), not VCV.

It’s JSON but yeah. All metadata in the VCV Library comes from plugin metadata.

Maybe ratings could make sense, but I find them kind of silly as an end-user. Try browsing around in the iOS App Store or Google Play store to see how ratings have virtually no correlation to your experience using an app.

The storefront for Rack plugins will be after it is overhauled/redesigned along with the launch of VCV Library. Yes, it will be biased toward VCV modules, but that is the point of having an unbiased VCV Library.

1 Like

I’m starting to get a clearer picture of how it will all tie together; but as I walk through the process in my head, I still have some questions on how this will work.

I’m thinking about this flow as an end user…

  1. I go to the library, I’m checking out some modules - maybe even thinking about buying something
  2. I find a plugin or module that looks interesting, I click on it to learn more
  3. There’s an info page that’s very lean on information about the module (how it works, etc.) - but it’s got a screen print so I can see it, and some tags so I know at a high level what it does
  4. There is also a link to the Plugin or Module website embedded in this page that will direct me to the manufacturer’s website where I can learn more about it - so I do that
  5. Now I’m somewhere else - where do I go to actually buy it? Will their site link me to a separate VCV storefront that I go back to?

I’m a process guy by profession (and nature honestly) so I can get hung up on thinking about the design and process flow of things, hence the questions. I’m also still not 100% how the store ties in, so maybe I’m just not getting that piece just yet and this is all accounted for in your plan already and I’m just wasting some keyboard strokes.

In my head, the most-convenient and efficient approach is a combined library/storefront. I browse for modules, I can add them to my rack just like the current site with the +Add button, or click on a page, get a basic product description, and add to cart right there to purchase. So the library is the storefront, and if developers want to maintain a separate site with more details/marketing/manuals/etc they can. Individual modules appear, and if part of a larger plugin/bundle, then clicking on the details takes me to a product page for the plugin.

If I can’t purchase from the Library and that’s not really it’s intent, then I could see people getting confused about why there’s this informational library for a product that I can’t actually go and make purchases from. Example: I don’t go to a public library to know which books exist and their topics, I go to a public library to read them or check them out for later reading. Hence the combined library/store-front assumption on my part.

And like any storefront, I still feel like there should be a product page with some basic copy. If I’m thinking about buying a module and I need to go to a different website for basic information about it, that’s going to throw me off. Do I buy it on this other site? If not, then where? Am I supposed to go back? Do the developers link back to the VCV store?

What I’m picturing isn’t really anything more than a “Product Description” type section on the library details for a given module, with an “Add to Rack” or “Add to Cart” button on the same page so everything’s self-contained. For more details, link to the Plugin/Module/Developer website (which you’re doing already), and maybe include a link to the manual if there is one. But this way, if I browse a cool module in the library, I can hopefully have enough information to decide if I want to add it to my Rack or buy it right there.

Regarding reviews: I may be an optimist, but I think your overall user-base will generate higher quality reviews than the iTunes user-base just due to the underlying complexity of the product. Good reviews (if achievable) would ideally help newbies and more experienced users alike explore modules. But particularly new users who may get overwhelmed by the number of options.

Anyway…sorry for another long post. Hopefully, my perspective adds some value. If you’ve already worked through this and I’m just not “seeing it” yet, that’s ok too. I look forward to what’s in store.

See the first post in this thread.

Yeah, true. Should be simple to add whenever I have extra time. Could try it for a “demo period” later.

but you are not the “normal” user and for me it is not obvious,
I think the user should be in focus not the creator

One ux thought: I went and searched the text field
For “vocoder” and got no hits; then cleared that and put tag to vocoder and got 4. The reason is none of the four vocoders seem to have vocoder in their name!

I wonder if you want the plain text search to also include the tags. From a user perspective typing seems a bit unnatural to have an empty search for that case?



There are no normal users here anyway, we’re all engaged in modular synthesizers. It’s a difficult thing, you know :slight_smile:

@baconpaul case about searching «vocoder» is more important. Personally i will type VCO manually instead of searching it in the list of tags.



I’ve improved searching considerably.
Queries are tokenized, so you can search multiple tags, such as “poly vco” to filter modules that have the “Polyphonic” tag and the “Oscillator” tag.
Descriptions are also searched, so you can type “synth tech e340” to search the real names of Eurorack modules, or “chebychev” for Chebyshev-based waveshapers that might not have the exact word in their name.

At some point, I’ll port this algorithm to the Module Browser in VCV Rack.


maybe the forum users are a bit nerdy, but now with more than 100.000 downloads rack will have more and more “normal” users, that want easy access, and should be treated well imho

1 Like

@Vortico: Will the library be the first chance to test the new plugin.json manualUrl property? I guess best thing is to push a build with valid manualURl’s in the plugin.json?