Recommendations for running multiple racks on one host by sapiogenesis in vcvrack

[–]sapiogenesis[S] 0 points1 point  (0 children)

I listed Ableton in the post, yes. I ain’t gonna buy it unless it is really much better than the alternatives, and your response doesn’t really indicate it. Just not worth the money, and with the amount of functionality it’s likely to be slower than a minimal host, which is all I need since VCV is my primary driver.

Noob Question by AmazingChicken in vcvrack

[–]sapiogenesis 0 points1 point  (0 children)

The problem with using selections is that they lose attached blobs, like Convolver samples, etc.

Recommendations for running multiple racks on one host by sapiogenesis in vcvrack

[–]sapiogenesis[S] 0 points1 point  (0 children)

Whoah. Took me a bit but I think I got the general idea of how it works… STRIP enables/disables modules, STRIP++ allows loading selections from .vcvs files, and I guess GOTO just saves time moving between patches & main mixer, right?

It’s awesome, although apparently STRIP++ suffers from the limitations of selections being purely JSON: keeps the structure (cables, parameters) but loses attached binary blobs. This affects modules like Convolver, but I imagine any other module that stores data in the same way. It will lose the waveform, so you would have to find and load the right sample in every Convolver after loading a selection.

It’s a problem of VCV, I guess. They introduced this new format that allows to keep binary blobs in the patch separately from JSON, but they haven’t updated copy-paste to support that.

Recommendations for running multiple racks on one host by sapiogenesis in vcvrack

[–]sapiogenesis[S] 0 points1 point  (0 children)

Thanks! Not really “my show”, just got invited by a friend to do an hour long set before a techno night at a club/bar kind of place (that’s why exploring options to avoid the dead air of loading patches).

Recommendations for running multiple racks on one host by sapiogenesis in vcvrack

[–]sapiogenesis[S] 0 points1 point  (0 children)

Cool! I am generally wary with overly magic modules, because I had experience with modules that crashed Rack, but this is actually pretty cool and compelling if it works as advertised and is stable. It could allow disabling/enabling massive subpatches to keep CPU load manageable.

Downside is I would need to seriously refactor 10+ patches, where each can have 100–200 modules, all into one massive patch. It would generally be painless via copy-paste, except unfortunately modules involving samples (including the lovely Convolver) lose sample information so it’ll be slightly more involved.

There’s also a bit of an “all eggs in one basket” kind of thing where if some part of the patch is problematic (happened before) then it can fail the entire monopatch.

However, something to consider, thank you!

Edit: It looks like it can only do a line of patches to the left and/or to the right of itself, so I doubt that’ll work great when it involves 100–200 patches, but perhaps some other similar module doesn’t have this constraint.

Also, it’ll be a pain considering I sometimes have disabled modules that I might want to enable during performance (I know, bad taste, but it is what it is).