"modules" property about library HOT 10 CLOSED

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

from library.

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

from library.

@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.

from library.

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.

from library.

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.

from library.

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.

from library.

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

from library.

For screenshots, the following questions need to be answered:

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

from library.

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.

from library.

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

from library.