"modules" property

[AndrewBelt]

This is a design proposal for adding a "modules" property with information about each module contained in a plugin.

{
    ...,
    "modules": {
        "VCO-1": { // slug
            "name": "VCO-1",
            "tags": ["OSCILLATOR"], // matches tags.hpp without the _TAG suffix
            "screenshot": "https://..."
        },
        ...
    }
}

A lot of things I don't like here.

• Redundancy with C++ code
  • The obvious solution is to include the manifest called plugin.json in the same folder/package as plugin.{so,dylib,dll}. But then how do we ensure that the same plugin.json file is used in the ZIP package and the community repository? We can't because of a circular dependency on the download URLs. Fundamentally, how do we distribute this metadata to both experimental plugins (that don't belong to the community repository) and polished plugins in the community?
• People will try to make up their own tags, but they should be fixed. Additional annoyance for developers.
• Where does the screenshot be hosted? Later, it could be solved with the web app idea below, but where should it be hosted then too?

Web app for creating/editing manifests

• Attached to your VCV account
• Can be used to monitor popularity

Disclaimer: The existence of an issue by me doesn't imply it will be implemented.

[fbeecher]

I'm not a developer, so I can't comment on the technical stuff. But I am a UX designer, so I can help think through the flow a little bit.

I feel like there are a lot of similarities between the task of selecting modules in Rack and the task of selecting modules on Modulargrid. On MG, you have basically an infinite assortment to choose from and you can add any amount of a single module to your rack. In Rack, with enough module plugins installed, you pretty much have the same thing.

I guess what we're thinking of here is a data model (???) for modules? If so, here are my suggestions (integrating Andrew's as well)

• Module Name (text)
• Module Short Description (text; for display in module list)
• Module Description (long text; for display in module detail)
• Primary function (single value; use list from Modulargrid)
• Secondary functions (multiple values; use list from Modulargrid; optional)
• Width (HP; some people are weird and care about this even in Rack. okay I mean me.)
• Author (text)
• Plugin (text; I assume authors will want to release multiple plugins?)
• Screenshot (png)
• Manual link (URL; maybe can be more generic "website link"; optional)
• CV Input Range (min/max; in "Volts"; optional)
• CV Output Range (min/max; in "Volts"; optional)

In terms of how this would work, I'm imagining that the current plugin-focused navigation would go away and be replaced by module-focused searching/filtering/sorting like MG. It still makes sense, I think, to do this in a modal.

• All modules (screenshots, names, etc.) would be displayed on load, in sort order of most recently added (updated?) to least recently added (words are hard)
• Users would search/filter/sort like on MG and that would restrict the list
• Users would have two options with a module
  • Add to rack: Pops it into your current Rack
  • Get Info: Displays detailed module info (long description, CV ranges, etc) in a panel of the modal

If this happens, we could potentially also make some of this info available from the right-click menu when you RC on a module. E.g., "website link" would be particularly useful, as would CV I/O ranges.

EDIT by Andrew: replaced pack -> plugin

[gbrandt1]

screenshots could be in further subdirectories for each manufacturer in the repo itself

[fbeecher]

@AndrewBelt It looks like you're starting to implement this. I'm a UX designer, but not a visual designer. Would it be helpful if I put together a prototype? It'll be black, white, and gray, but the interactions will be solid.

[AndrewBelt]

I have a deadline to meet, so any changes will need to be wrapped up in ~4 hours of effort. But you're welcome to send some ideas. Keep in mind that I already have a graphic designer who would work on this if I asked, but I won't say no to opinions.

[fbeecher]

Alright. Probably can't be useful on this one then. Let me know if you need help working out interaction ideas in the future. Happy to collab with your graphic designer.

[AndrewBelt]

Okay, going with the following schema.

    "modules": {
        "MyModule": {
            "name": "MyModule",
            "description": "A simple sine oscillator for demonstrating the Rack API",
            "tags": ["vco"]
        }
    }

This will be in plugin.json and will actually be required for all modules.

[AndrewBelt]

Here's a full example from the Template plugin. https://github.com/VCVRack/Template/blob/7c28f8d276e51d9d2c8e8de639e6823648c97e8c/plugin.json

[AndrewBelt]

For screenshots, the following questions need to be answered:

• How will the screenshots be created?
• Who will create them?
• Where will they be hosted?

[dizzisound]

A few freewheeling ideas, to feed the heuristic phase...

• The screenshots could be created/maintained in the first instance by the module developers themselves, so that the work can be distributed among more "proactive" (sorry for this someway misused word) people, and the subsequent releases/updates can be directly supervised by the authors/owners of their plugins.
• The updated screenshots could be hosted in some auxiliary folder (e.g. named \<meta>, \<gallery>, or whatever) added to the plugin source-code folder structure (beside the \<res>, \<src>, \<dep>, etc. folders).
• It should be fine if the catalog could be hosted in a centralized, VCVRack-related sub-repo on Github, or better the images could be uploaded or cloned in the VCVRack/library repository, and grouped by plugin (as in this example), so they could be fetched or manipulated more easily by some maintenance script.
• The naming of the captures should be consistent with the plugin slug, the module name and the last released version for the plugin (in order to make eventually possible the automation of naming-based query operations).
• The global maintenance and supervision of the collected images and/or the related gallery could be task of the VCVRack Review or Library support teams.

[AndrewBelt]

Closing since the "modules" property was added in Rack 1, and feature requests are now handled by VCV Support.