Module Hot Swap & Unified Patching Menu

Feature Requests
1

I believe the UI workflow for patching and module management could be significantly faster. I’d like to propose two workflow enhancements:

  1. Module “Hot-Swapping” (Replace Module)

Currently, if I want to try a different Oscillator or Filter, I have to delete the module and manually re-patch everything.

• Suggestion: Add a “Swap” or “Replace” option when clicking a module.

• How it should work: If I swap a VCO for a different model, the Meta Module should attempt to keep the existing connections (e.g., the 1V/Oct input and the Primary Audio Output) mapped to the new module’s corresponding ports. This would make auditioning different modules in an existing patch much more fluid.

  1. Unified Destination List (Internal & Physical I/O)

Right now, switching a connection from an internal destination to a physical output (or vice versa) feels disconnected. You often have to navigate separate menus or disconnect first.

• Suggestion: When selecting an active connection/cable, provide one unified list of all possible destinations.

• How it should work: This list should combine all Virtual Inputs/Outputs and Physical Hardware I/O in one view. If I decide a signal shouldn’t go to an internal VCA but directly to physical Output 1, I should be able to make that switch in one click without leaving the menu or deleting the cable first.

  1. Direct Connection Logic

To speed up patching, the Meta Module could “predict” the connection. If I select an Audio Output, the list should prioritize Audio Inputs or Physical Outs, rather than making me scroll through every parameter.

The Meta Module is a game-changer, and making the interface feel as “instant” as physical patching would take it to the next level. Curious to hear your thoughts!

2

some nice ideas, though I think there are some practical issues…
and I agree, with the general premise, that the patch connection logic , is very menu / modal heavy
(though given flexibility, and form factor of one push encoder, Ive a lot of sympathy for why it is as it is)

attempting to match IO - there is not a lot of consistency with port names.
v/oct is perhaps the exception to the rule.

related, to this ‘predict’ connection - vcv does not differentiate CV and audio IO, so it doesn’t know what is an audio input (or output) vs a cv input/output.

its also worth bearing in mind, these ‘names’ are (generally?) used for tooltips, the labels you see on a panel are (generally) unrelated to the port, and for the most part internally vcv uses a simple index number for the ports (which is why the text is ‘free form’)

in both cases, the best you could use is some kind of ‘fuzzy’ logic / naming to correlate) port names e.g. look for matches/ partial matches / remove spaces,/ synonyms etc - the success of this would be very module dependent (both module being replaced, and the new module)

(e.g. imagine some cases of “in 1” “in 2”, “out main”, “out aux”, “cutoff in”)

again, not dismissing it… just pointing out that vcv does not really have the ‘meta data’ thats required to do this sensibly… pretty much just has input and output ports with a free form label.

perhaps using fuzzy logic is ‘good enough’, but its going to fail in a lot of cases.

1 Like
3

Thanks for the feedback. I see your point about the lack of standardized port metadata in VCV; that indeed makes ‘smart’ re-patching tricky.

However, I still believe a Module Hot Swap would be a great addition, even if connections are lost during the process. Just being able to replace a module in its current position without deleting it and diving back into the browser would save a lot of time and keep the patch layout organized.

1 Like
4

The alternative to fuzzy logic would be to create the necessary metadata — define a set of swappable connection types (v/oct, audio out, filter frequency, wet/dry, etc.) and manually add the data to the several hundred modules in the library (and require it for future modules). It’d be a bit of a pain but not impossible if this feature were seen as worthwhile.

1 Like
5

Exactly

6

yeah, I don’t see that happening as a ‘mandatory’ requirement, way too much effort (at least for the benefit), also consistency would be hard for many modules types. ( * )

ofc, it could be made optional for modules, and then use fuzzy logic as a fallback.

but that makes things inconsistent, and im not a fan of features that work ‘sometimes’.

( * ) its easy to just think of oscillators where its reasonably straightforward, have similar inputs. but looking at the broader picture - modules are often not even easy to classify, let alone define standard IO for. also often inputs / outputs can change depending on modes or other inputs etc.

so the effort to add meta data to IO could be difficult , and likely subjective for many modules.
also, arguably thats the beauty of modular - we abuse IO all the time :laughing:

7

Also true. The module hot swap feature would work perfectly fine even without a standardized connector convention.

1 Like