Some DAWs do offer sandboxing of plugins (VSTs). Bitwig does.
I seriously doubt that sandboxing can work well or perform for modular and preserve performance. Certainly would require a different design and require rewriting all modules.
VCV chose another route that allows plugins innovate on the Rack UI, something that’s impossible in the DAWs. This does come at the expense of potential instability, but that’s trivially solvable by users without reinstalling Rack: just don’t use modules that crash Rack. There are plenty of other options available.
That mandate would mean some developers would simply not make modules for Rack. Not even high-end commercial DAWs require that of their plugins (VSTs).
Docs are great (I document all my plugins). Many users never bother to even look at the docs when they are provided. Lots of users only want videos.
If it’s a blocker for you, then don’t use modules that don’t have docs. Even if docs are just online, most browsers provide a way to download pages or save pages as PDF.
Guys it seems that that “shell” about i wrote is not exactly the same what you mean as sandbox (like yes i heard there is in Bitwig).
Sandbox (as i understand it, but i may be wrong) its for cases when crash of plugin does not have affect to program work (in current session, when occurs crash). That really can say like exotic shell.
But i meant more common thing i think, like some principle that not allowing change program’ resources at all.
For example Studio One. So, by principle i’m talking about, all his resources which place in “Program Files” can’t be changed by plugins.
All what can be affected by plugins (and by user settings) are placed in “C:\Users\username\AppData\Roaming\PreSonus”, and all what placed here, can be even deleted manually, but it not break program.
That “shell” what i mean.
And the same principle have all popular hosts i think.
I have never seen that any of installed\runned plugins produce changes (for permanently) for something in Studio One, Ableton, Reason, or Bidule.
As someone who uses VCV on a 2-in-1 laptop, it’s really disappointing not to have multi-touch support.
Being able to twiddle multiple pots, finger-drum on pads, and adjust multiple faders when playing a patch is a big part of performance and working with actual hardware. Using laptop touchpad+keyboard for building a patch then folding the laptop into tablet mode for live performance (or detaching from the keyboard in the case of Microsoft’s Surface devices) should be an effortless thing that gives the best of all worlds.
Right now VCV feels like having $20K worth of modular hardware of my disposal but all my fingers have been removed save for one pointer.
This would be a welcome little improvement, yes! All in all, just a boolean toggle somewhere in the UI, show module images in the module browser, on/off. If images are toggled off, show modules as their names (text) instead.
Show / Hide Cable Shortcut & Shortcut to change transparency.
Command C = toggles cables — Command [ = increase opacity — Command ] = decrease opacity
I know that stoermelder created a module to do this as well and am very thankful but really think this should be a built in feature.
Someone has already mentioned it in a previous topic but thought I’d reiterate here as I think it would be a very easy but life changing addition to VCV rack.
As a patch gets complicated the overlay even at a reduced opacity can be extremely distracting and for me at least impairs my ability to read / comprehend module interfaces.
both MaxMasp & Reaktor have this ability and it makes for a nice clean interface when your patch is all locked in an you just want to play / perform.
Those shortcuts are already in use (I think – I’m not on a Mac, so there isn’t a “Command” key).
If it’s just for performance, easy enough to use the menu to reduce cable opacity to 0 before the set - no compelling need for a keystroke for that purpose, but yeah, a quick on/off key would be handy.
Upvote multitouch, even two or three inputs would change so much about performing, playing and using vcv. I certainly am inspired to think about possibilities…
FWIW, adding touch support has technical challenges: input events are handled by external dependencies (GLFW), and not Rack itself.
GLFW has taken a policy stance to not take any changes unless the feature work for all platforms (including Mac). So, until Apple adds touch to MacOS and Macs, GLFW isn’t interested in supporting touch. Never mind that you can use tablets such as WACOM tablets that support multitouch and work on Macs.
Rack would have to use a fork of GLFW that contains that touch support. There is a PR (patch) that adds that support to GLFW for Windows.
I don’t know if anything has changed since I researched this a year ago. I understand a reluctance to maintain forks of your dependencies - that can get expensive.
I’m not expecting much to change in the short term, but feel free to surprise me!
Slightly more frequent library updates would be nice. I know ultimately this is just me being impatient but when you hear a dev has already submitted an interesting module/fix to the library, and then it takes over two weeks to arrive (maybe sometimes even significantly more?), it kind of makes me wish updates were at least a weekly affair. Perfectly understandable if this isn’t practically feasible; anyway, the thread asks which improvements I’d “like to see most”, and that’s one of the main such things anyway
Adding menu items isn’t particularly painful. It’s mostly boilerplate. Of course, if you provide user control over the normalled value, then you also need to provide persistence for that custom value, or saved patches don’t work the same when reloaded.
It would be pretty complicated to provide an API for this - there would be a lot of cases to cover if it were to be generally useful. Inputs don’t have something like paramQuantity to hang such functionality from, so it would need to be added. It would need to be opt-in, and cover cases where you want a number of inputs normalled to either the option value or cascaded from another input. It’s probably better left to each module to define the logic that makes sense for that module.
M1/Arm, which includes something else…
A NanoVCV Rack for the DS…GBA???
3DS family has the Korg semi-modular, Nanoloop, LSDJ, C64 emul with various trackers, UAE Amiga emul, with even more stuff than the C64… far superior hw than DS or GBA, but no updatable cartridges…
which Nanoloop and Oliver Witchoff creates and sells to thousands of
Chiptune enthusiasts…
Maybe a low resources ARM version could be done for the DS??
Android and tablets also run on ARM, but Nintendo DS has the cartridge market, which could be a nice boost to the project in terms of sales…
This one is a small/simple one, but would make life easier:
A keyboard short cut for turning favorites on/off, when in the module browser. For example on Mac it could be option+f, which doesn’t seem to collide with anything in the module browser.
That would make the module browser a bit easier to use.
And in general an update of the module browser. Liked the old one more, I think it was easier to find what you need fast.