Rack: Core Macro

[Skeyelab]

I find as my system grows, I am wanting to reconfigure things. It would help a ton if I could select a couple of modules that are next to each other in the same row and ‘group’ them and move them as one.

[Ahornberg]

Yes, and not only to move them as one, but also to save them as one. In my mind something like the Combinator in Propellerhead's Reason would be a possible solution. On the other hand, VCV Rack mimics hardware very closely and as far as I know, a module like Reason's Combinator doesn't exist in the Eurorack world. I don't know if Softube's Modular or Native Instrument's Reaktor Blocks do have solutions that could be applied to VCV Rack. One Suggestion might be the ability to load/save a single row in the rack. Of course this would mean that cable connections from and/or to other rows in the rack can't be saved and also can't be restored after loading. The idea behind this is to treat every row in the rack as a separate rack.

[danballance]

Creating virtual instruments out of collections of pre-configured modules would be really useful. Say for example setting up a polyphonic voice made from VCOs and a quad midi in. It can take a while to set this up and doing it for every track seems a waste. If these could be saved (and moved) as an instrument that would be really helpful. These configurations could also be shared between users.

To my mind it would be kind of like a partial view in MVC parlance - and have perhaps it's own format like vcvi for vcv instrument. Opening on of these files doesn't start a new project - instead it would import into the current project.

[AndrewBelt]

I'll call this feature Core Macro. It will require separation of Module and ModuleWidget, so that one can be created without the other. There are dozens of design problems that will need to be solved for this feature.

• The exact ".vcv" format may be used, but a different extension might be useful for users to distinguish. ".vcvi" makes no sense. ".vcvm" is better for VCV Macro. However, a Macro Connections module with 8+8 outputs and 8 inputs will need to be used instead of an Audio Interface, so that the Macro module can have 8 knobs, 8 inputs, and 8 outputs.
• The Macro module will need to have a load button to load the .vcv files.
• Saving a patch with a Macro module should embed the subpatch in the JSON patch.
• I don't think a modification to the rack engine is required. The Macro module would simply add/remove modules and wires from the patch to the engine when loaded/unloaded.
• Users will want to edit the subpatch, so the GUI scene will need to be able to render subpatches. A toolbar icon with #565 will need to be added to go back one level. Yes, Macros may be arbitrarily deep.

[maxmcorp]

I believe that a tabbed interface would be a better solution for reuse and distribution. Especially if Rack is to be used efficiently and for more structured music too.

I have attached a picture of main gist of the idea. A Rack window with several tabs. A simple tab could be a Prophet 1, SH101, 1 drum machine, an algorithmic cv generator for song length tracks. Etc. etc.

Intra tab communication could then be done via a "patchbay module". I have added a simple example in black and red just as a simple example. The patchbay could also just be a "1U" band between the row as seen in some hardware cases. But a patch module that is not part of the core would probably be more flexible.

The tab and patchbay would also be a good interface for racks running on different computeres, if that is something that happens in the future. it could perhaps even be a CPU core per tab to make that possible

Perhaps a tabbed interface would even use less GPU as only one tab at a time need to be drawn.

[Scumbag01]

If I read this correctly, you're essentially treating a tab like a skiff of modules? I do like the idea of virtual skiffs of modules that one can import and export at will, pre-patched, and ready to insert into a Rack by simply connecting cv/clock and audio cables. A skiff with one or more MIDI-CC core modules already addressed to one of several hardware controllers, just connect the cables to a Southpole Snake and pop another one or several up in a cluster of modules and set-up time is reduced, and one can get to playing the modules in no time flat.

So when envisioning a macro module, does one just select a Macro module then open the right-click menu, and load like one would load samples into Nysthi's Simplers? Modules connected to the Macro and their settings are recalled in the physical placement and with the parameter settings when the Macro was "saved as"? Perhaps Macros might use a particular color or thickness, or texture of cable that is unique to them to, as well as distinct plug ends so as to be visible even when cables are displayed at zero opacity?

In stating that Macros may be arbitrarily deep, does this mean that more than one Macro can be "clumped" together with others? Would one then be designated the Master Macro which the configuration would be saved under? Does this also mean that perhaps by disconnecting cables between Macros, they can be separated and handled as discreet clusters to then be added to another, possibly larger cluster of Macros and connected modules? Maybe to enable the movement of multiple modules, when connected to a Macro, they all move together if the macro is moved, and moving individual modules when connected to a Macro is just for arranging their proximity to the Macro they are connected to? Perhaps to avoid mayhem, modules should only be capable of being connected to one Macro at a time. Thoughts?

[gabrielreygoodlatte]

Just want to note that this isn't labeled as a feature request (I found it before, was looking for it and had some trouble finding).

This would be so amazing. It would allow us to build tools that are easily reusable, and I think it could lead to people sharing/reusing small patches a lot more (it's a big workflow improvement to have something that you can easily load into an existing patch, versus having to open a file you downloaded, cut something out of it, save it with strip or whatever, then bring it into whatever you're working on).

I think integrating these macros into the browser in some way would also be really helpful; they should be able to be browsed and added like other modules.

This would also be really helpful for reducing visual clutter, having better visual organization. That's achievable other ways too, but once a patch starts getting pretty big, it can get clunky to have to scroll around so much. Another relatively simple interim solution that would help on this level would be the ability to expand/collapse certain rows (perhaps along with the ability to label and/or color code the row).

[AndrewBelt]

Just to encourage useful discussion:

• How would a user create a "macro patch"?
• How would a user add the macro patch into their "parent" patch?
• I assume you'd have a few knobs, inputs, and outputs on a "VCV Macro" module, which would correspond with a few CV outputs, outputs, and inputs (resp.) on a "VCV Macro Host" module. How would this work?

[gabrielreygoodlatte]

One possible approach:

• There is a "Macro Host" module. A few sizes of these -- 2 ins/outs + 2 knobs, 4 ins/outs + 4 knobs, etc. Or, one module with an expander for more ins/outs and more knobs.
• Any patch can be turned into a macro patch by adding a "Macro I/O" module. This has CV outputs that send CV from the macro module's inputs, and knobs. It has inputs that route to Macro's outputs.
• Perhaps: if a patch doesn't have a Macro I/O module, Macro can still load it, and will treat any audio i/o module in the patch as the Macro I/O module (the audio interface's inputs and outputs become Macro I/O's ins and outs). This is probably useful when there is a VST version, as it will allow us to create patches that could be usable both as a VST instrument or effect, and as a subpatch within other VCV patches.
• If a 2x2 Macro tries to load a patch with an 8x8 Macro I/O or Audio interface module, it gives a warning and uses only the first 2 ins/outs.

One important thing to figure out is how to manage whether Macros are a part of their parent patch's file, or whether they are their own independent file. Might be worth looking at how Max/MSP does this -- both are possible there, and it works nicely. Dealing with this definitely increases complexity, so maybe to start you just have one or the other.

Some thoughts on how it could work:

• Macro can load patches from a file, or create a new subpatch (and either save it within the current patch as part of its file, or save it independently as its own file)
• (maybe obvious) Each Macro module in a patch represents a unique instance (two Modules can't communicate with the same subpatch). If two modules load the same file, you have two independent instances of that subpatch.
• Duplicating a Macro module creates a new instance. If the duplicate module contained a subpatch that was linked to a file, the duplicated module will also be linked to that file (and changes made to that file will propagate to all instances). If duplicate module contained a subpatch that is part of the main patch, then you have a new, independent instance. Edits to the duplicated module won't propagate to others.
• When Macro has loaded a subpatch from a file, there is an option (in right click menu) to convert this subpatch to one that is incorporated in the main patch (based on what was in the file, but no longer linked to it). Not sure what this should be called.
• When saving a subpatch that is its own file, parent patch is told to update all instances of that subpatch
• When editing a subpatch that is part of its parent patch (not its own independent file), there is a "export subpatch as ..." option in the file menu. This outputs a copy of the subpatch as its own file, but does not link this Macro module to that file (if you want to do that, just reload subpatch from the file you just saved).

• If using "Macro host" to load a file when it already has a subpatch loaded that is part of the main patch, there should be a warning about losing changes to the subpatch (and an option to save/export)?

• Ability to use relative or absolute paths for pointing to files. Ability to edit these as text (not just using file system browser)

• Ability to relink subpatch files that aren't found

[AndrewBelt]

will treat any audio i/o module in the patch as the Macro I/O module

This is the problem. VCV Audio isn't a "special" module. How is Rack supposed to handle it specially? What if someone creates their own module that communicates with an audio interface or other protocol? How is Rack supposed to handle that?

Instead, I think stoermelder Strip's approach is the best direction. It allows reusable collections and purposely doesn't hide the modules, or their patch points. It cleverly avoids getting into the mess of >1 nested patches.

Let's go this direction. The final proposal might look like Strip, or completely different, but I think it should be based on it.

[gabrielreygoodlatte]

This is the problem. VCV Audio isn't a "special" module. How is Rack supposed to handle it specially? What if someone creates their own module that communicates with an audio interface or other protocol? How is Rack supposed to handle that?

How are you going to deal with this in the VST version? Won't the potential configurations of ins/outs in the VST version be somewhat limited (I imagine there will be a stereo instrument, a multichannel instrument, a stereo effect, and a multichannel effect)? When the VST version comes out, I would imagine people will be building a lot of standalone instruments and effects meant to as a single instrument or effect in another DAW. It would be cool if those could also easily be loaded as Macros. I would think that you could just support the standard VCV Audio modules, and throw an error if none of those (or the Macro I/O) module is found when trying to load a rack as a Macro.

Instead, I think stoermelder Strip's approach is the best direction. It allows reusable collections and purposely doesn't hide the modules, or their patch points. It cleverly avoids getting into the mess of >1 nested patches.

If done in the right way, this could probably still achieve a lot of what I would want out of this feature. One key thing, I think, is having inputs and outputs that can stay patched while what's inside the Macro changes. This would allow us to relatively quickly audition different Macros we've created in the context of a larger rack.

Personally, part of what I actually want is to be able to hide the modules and reduce the complexity of what's in front of me, so I can focus more clearly on what I'm trying to work on at the moment. I get there are also reasons for not wanting them hidden. Maybe the Macro could be collapsed / expanded. I guess that would require moving other modules around too.

[AndrewBelt]

How are you going to deal with this in the VST version?

There will be a new audio and MIDI driver called "Host" which will communicate with the plugin host instead of audio hardware.

Maybe the Macro could be collapsed / expanded

That's probably the best direction. Might be a Rack v3 feature.

[gabrielreygoodlatte]

Cool. But just as food for thought - what if there was no distinction
between “Host” and the “Macro I/o” module I described? If the module is on
the top level of a VST instance, it’s Host; otherwise, it’s macro i/o. That
would make macros and vst racks somewhat cross compatible. There would be
some macros (like things oriented towards processing cv) that wouldn’t
really work or make sense to load as vst instances. But everything created
to run as a vst instrument or effect could also work as a macro. That might
create more interaction and sharing between folks using this as a vst and
standalone. Would also make it easier to quickly move ideas back and forth
between vst and standalone.

On Sat, Nov 9, 2019 at 2:22 PM Andrew Belt [e-mail] wrote:

How are you going to deal with this in the VST version?

There will be a new audio and MIDI driver called "Host" which will
communicate with the plugin host instead of audio hardware.

Maybe the Macro could be collapsed / expanded

That's probably the best direction. Might be a Rack v3 feature.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/VCVRack/Rack/issues/655?email_source=notifications&email_token=AFJXJ2VHRPAYLB443EEZ3NDQS4S25A5CNFSM4EODFQFKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEDUPSAI#issuecomment-552139009,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AFJXJ2WONWQZ5Q3SULAXVSTQS4S25ANCNFSM4EODFQFA
.

[maxmcorp]

I still think that a tabbed interface of virtual skiffs would be a good solution. No recursion in the interface. Easy sharing of tabs via files. like now. Consistent interface, that could even be made to work across ethernet via a network patchbay module. (Albeit with some lag.)

But there might be something I have missed. Any reason for it to not be a good solution?

[JP01]

This is the problem. VCV Audio isn't a "special" module. How is Rack supposed to handle it specially? What if someone creates their own module that communicates with an audio interface or other protocol? How is Rack supposed to handle that?

I see this as a similar problem that people face in in node based visual effects software (for example SideFX's Houdini or Foundry's Nuke).
While it's certainly possible to communicate "outside" of a nested node, a general rule is that nested nodes can only communicate to their parents.
IE in the context of VCV, if you want to make a module that communicates to an external audio source, you have to create it at the top level.

All sub-patches would only have access to a macro i/o module.

• You create a "Macro Module" and then "dive-in" to find a configurable Macro-IO module. This could simply be an audio module that can only have "macro-io" as a driver or something.

• You can still have arbitrarily deep nesting, but with the clause that anything inside a macro module only has access to Macro-IO which can only communicate with it's parent module.

Correct me if this isn't possible, but I believe this could be achieved by tracking what "level" or "context" you're currently at:

1. Launch VCV Rack -
   _Top Level / Root Context (The only context available as of VCV 1.0.6) - audio IO behaves as usual_

2. Create a Macro-Module and "dive-in" (double click? right mouse-menu?)
   _Macro/Sub-Patch Context - audio IO driver can only be set to Macro-IO (maybe we do the same for midi io because it probably will have the same problem)._

_Fig 1. A simple filter subpatch with LFO as input audio and second LFO as modulation._

The idea being that internal modules all operate as usual, but you can "expose" certain I/O and/or knobs to the parent module.
If someone wants to modulate a sub patch using external audio/midi, then they just have to properly expose the internals to the Macro-IO and do the external modulation via the top level context.

Alternatively, just copy paste the modules from the internals out to the top level context and work as normal.

I think something like the Stoemelder Strip would be useful for sharing "top level" patches, but I think there still could be a use for "sub-patches" like this.

I was going to have a go at implementing something like this just to see how it could be done.

[oletizi]

If Rack could be used as a VSTi plugin, I would use Host to use Rack as plugins for itself.

[Coirt]

To be pedant I believe my closed request was the first mention of this request #579

Not that it matters... 😄

[gwatcha]

By the way, to audition different modules quickly, Little Utils Teleport In/Out is very useful in combination with stoermelders Strip. Using it, you just delete the 'Strip' and load a new one and don't have to connect any wires.

Simply include some 'teleport out' to act as module inputs, e.g. 'Instrument Player' or 'Midi CC', or 'FX Audio'. Then put a 'teleport in' at the end to define the output e.g. 'sound source out'.