I had an idea that is similar to a “favourites” but actually for essentially batches (or “blocks” as i called them) of plugins that would save alot of time putting patches together on the MM. Eg: if i always use a specific oscillator with a specifc filter, and have that saved as a block. Or a clock+gate seq+eg combo. Just an idea ![]()
I’ve wished for this too — there’s an equivalent in VCV Rack called selections. It’d be great to be able to easily load a predefined set of modules with cable routing between them. (I don’t think you could save knob sets or panel cables, because when you went to load a “block” you’d probably already have knob and Jack assignments in your patch.)
I don’t think vcv selections are anything more than patches ?!
vcv main functionality here, is it to allow you to select within an existing patch, and remove connections outside of the selection.
I think you could simplify this on the mm by simply saying
- you create / save ‘blocks’ as normal patches.
- allow user to load a new patch (which happens to be a block) whilst not removing existing patch.
as @gabrielroth said, you’d get clashes with knob (and likely midi) assignments, but you could say thats ‘on the user’ at least for first simple implementation.
I agree, later, it be v. useful, to do something like load all knob assignments into new pages.
panel cables, I think is on the user.. if you save intending to use as a block, you simply don’t patch panel cables ?!
(probably patch settings conflict e.g. SR / block size used)
I guess, it be useful to some how separate ‘blocks’ from other patches, e.g. different file extension. but perhaps that complicates things (e.g. now the loading patch screen has to take this into account).
overall, I think you’d get 90% of the functionality, with a simple option of ‘load without clear’.
that last 10% is then ‘on the user’ , save blocks with names you recognise e.g. ‘B-’ prefix, dont save knob/panel assignments. at least for a first ‘go’.
note: from an implementation perspective, its likely more complex than this.
id expect theres a lot of initialisation code, that goes on during patch loading.
so, Id not be surprised if theres various code expectations, that will have issues with ‘just not clear the patch’ and then start loading new modules ![]()
I mean personally i meant just the modules on their own, no patching. Lets say like a set of lfos and a mod matrix. Though yall are right that this would very much only be a minor streamlining, and that with the additional points mentionned, it is essentially saving a patch so it becomes more redundant in alot of ways ![]()
I feel like adding modules is pretty simple but remembering and recreating even vaguely complex routing is more of a pain.