I work on multiple patches, and of course sometimes module updates affect the sound. Depending on where the module is used, the change can be quite drastic. Thus, once I get far into a patch, I consider any modules used in it immutable (no updates allowed). However, in a new patch I might switch to latest module versions.
Right now I use a cumbersome approach where I keep various copies of the “plugins” dir and try to swap them in according to the patch as best I can. I might script it but it’s not going to be pretty anyway.
The most thorough way to address it, in my opinion, would be either version-specific module instances or per-patch module version lockfile[0]. Of course, that brings in a couple of new features around version management and would complicate GUI for new users, so that’s a tradeoff. However, this would go a long way towards overall predictability, which is IMO one of the few weak points when VCV is compared to hardware modular.
Other than that, a partial solution could be allowing to select a specific directory as Rack’s “home” (with modules and all), for example at Rack launch (e.g., holding a specific modifier key would invoke library folder selection dialog).
[0]
In case of versioned module instances, each instance of the module specifies exact version (this means a patch can end up having different versions of the same module)[1]. In case of lockfile, the patch package includes a manifest which states which module uses which version (module version would be patch-global).
Rack still maintains a global library of modules, but with subdirectories per module (or rather plugin/module library) version. When loading the patch Rack would load specific versions of modules. If a version is missing, Rack would have to fetch it.
Alternatively, if Rack can require all modules to be Git-versioned, Rack’s library can keep a bare repository for each module library, and have a layer that loads module data from repository tree at specific commit hash[1]. This could save disk space, because Rack wouldn’t need to keep multiple working directories for a single plugin. This would also make fetching missing versions unnecessary most of the time, unless requested version is too new and does not yet exist in the local clone.
User would have to have an ability to bump specific module versions, either because they want to adopt a newer version or because they are offline and desired version was not fetched but another version is available. In case of lockfile, this action would cause an updated lockfile to be stored the next time the patch is saved.
[1] I had to implement something similar on a project before. In my case, extensions used specifiers like <repoURL>#<commitOrTag>/<extensionSubdirectory>. I used bare repos with a layer that would read objects under specified subdirectory and specified commit or tag, and return the result in one structure like { '/path1.png': binaryArray, '/anotherPath.txt': binaryArray2 }.
This is reality. It’s impossible to guarantee that module sound would not change. Even if module author fixes a bug, sometimes this bug is what I relied on for particular sound.
A module that does not change its sound does not become better, and if we require every single change and bugfix to come with an optional switch then this means a) modules become complex and b) their GUI becomes complex.
There are a lot of excellent, free modules that people share for everyone to use. I think the best we can do is encourage more people to keep doing that, instead of holding them to unrealistic standards and calling their modules “bad”.
There is a command line option to point to a different user folder. You could keep checkpoint copies of the folder, and set up operating system shortcuts to launch a given checkpoint.
Modules are not versioned – only plugins. The unit of installation and update is the plugin. All modules in a plugin are in a single dynamically loaded library. It is quite common for modules to share a lot of code. Their independent-seeming existence is a user interface illusion. So what you’re asking is really not realistic for Rack2.
Why would a module need to change its sound to “become better”?
If a module kept changing how it sounds, I wouldn’t use it. What’s the point of spending my time learning to use a module if it might arbitrarily change to something I don’t like later, with no way to get the sound I liked back? I doubt many modules are out there intentionally changing how they work without providing an option to revert that change.
I agree with Squinky, if a module keeps breaking old patches for no reason, that’s not a good module.
I’m not gonna point any fingers, but I once changed the clock module I use exactly because it broke my old patches.
This is a case where we could debate whether or not somebody should want to do this, but everyone has different motivations, purposes, and a different way of subjectively weighing pros and cons, even when those pros and cons are objectively true facts. Somebody who is using VCV Rack as a professional musician may have different requirements than those of us who use it as a hobby.
@sapiogenesis, it sounds like what you are looking for is the ability to know with near certainty that you can create a patch, get it to do what you want, and for years later that patch will behave exactly the same. I’m also guessing that reassurances from plugin developers (like me) who sincerely tell you we bend over backwards to avoid breaking backward compatibility is nice but not certain enough. That’s cool, I get it.
Part 2
So here are some ideas in the form of questions, since I don’t know the answers to them.
Can VCV Rack be run from a Docker/Kubernetes container?
Can VCV Rack be run from a virtual machine?
Can you go “old school” and put VCV Rack, your plugins, and your patch on a DVD-R disc? You’d have to fit everything inside 4GB. Maybe it’s possible?
If you can get something like one of the above to work, it would provide you with something more archival in nature.
Part 3
Just in case, this needs to be mentioned. Just because you run the same patch later and it sounds different, doesn’t mean anything in the modules has changed. Some modules (including a couple of mine) sound different at different sample rates. The sample rate itself is a parameter that affects the audio.
Add to this that you might set Engine / Sample Rate = Auto, and the same backup will sound different on two different computers if the audio card is configured differently. There might be other variables that could affect the sound I don’t know about yet.
So even if you completely archive VCV Rack, all the plugins, and your patch on some kind of backup, it’s possible years later it could sound different for some other reason. It’s worth testing your backup right after
you make it, and on different computers if possible.
Why would a module need to change its sound to “become better”?
Sorry, but this shows some lack of understanding. There is no “changing of module sound”. There is a change in module output (given the same set of inputs). That change, in turn, affects the sound of the entire patch, and it can happen in unpredictable ways because minor traits of module output can be amplified and relied upon by downstream modules.
Be it as it may, the short answer is “because module maker wants to”. Many people publish modules they use themselves and the wider community would benefit if they kept doing so without negatively affecting patch authors, if the latter had an ability to pin module versions.
I agree with Squinky, if a module keeps breaking old patches for no reason
This is not about “keeps breaking for no reason”, this is about “breaks once in a blue moon for a good reason”. For a composer, it doesn’t matter how rarely it happens, it’s always a problem, and what is legitimately a good reason for module maker (maybe it crashes the patch!) may not be a good reason for patch author who is working on recording a release for example.
That sounds ideal, but to be honest it would be still massively useful even if it was not necessarily “years”. Here’s a specific scenario:
Musician is working on a patch and likes how it sounds.
Musician found some new modules and wants to add them.
Musician finds that adding a new module from the same library/plugin/repo requires bumping the entire library, meaning any pre-existing modules may behave slightly differently.
Just in case, this needs to be mentioned… Some modules (including a couple of mine) sound different at different sample rates. The sample rate itself is a parameter that affects the audio.
This is a great point, and I think I noticed with some samplers which “accidentally” (but again, this could be something some patch authors want!) repitch sound if the original file uses a different sample rate. Some modules accommodate resampling, some don’t, and I think it’s fair play either way.
Add to this that you might set Engine / Sample Rate = Auto, and the same backup will sound different on two different computers if the audio card is configured differently. There might be other variables that could affect the sound I don’t know about yet.
I think this is fair to note. However, there are still realistic timeframes when a producer works on some piece—using one machine, one set of audio equipment, one VCV Rack version—and avoiding uncertainty even within these shorter timeframes would be a big positive.
Here my knowledge of the runtime is slightly fuzzier, but I think it would work this way:
Module A and module B belong to library (plugin) X. They both use common lib C.
At runtime, module A is instantiated from X commit abc, module B is instantiated from X commit def (using some approach I described in original post).
Module A gets instance C, and module B gets instance C’. Which is not a problem aside from performance impact, assuming modules do not literally share runtime code (i.e., communication between modules happens via a normalized way through cable or expander mechanism, not through direct memory access).
There is a command line option to point to a different user folder. You could keep checkpoint copies of the folder, and set up operating system shortcuts to launch a given checkpoint.
This is handy to know, thank you. It may help work around the immediate pain point, though without the extra benefit of patch module manifest.
Yes, this is a simpler scenario. As @pachde mentioned, you could make backup copies before updating. Specifically, you could make a backup of your plugins folder, e.g. plugins-win-x64 (on Windows; adjust for your OS+processor). This is where all the plugin binaries are stored. After updating the plugins from VCV Rack, if you don’t like the result, wipe out the plugins folder and restore it from your backup.
Yep, I’m already doing backups and per-project VCV configurations. It’s just very unwieldy, that’s the problem. However, @pachde mentioned a command-line flag for custom library folder, that will make that juggling somewhat simpler.
Thanks for the link. I suppose --user and --dev flags are going to be helpful in my scenario. --dev basically means I could keep complete per-patch setup, including plugins and even Rack itself next to the patch.
These flags will help script things better. Not really on par with module version lockfile/manifest though, I foresee more requests for such a feature, and if Rack works the way I think it works then that is doable.
I’m doubly happy you joined in this thread, because I just thought of maybe the best example that was staring in my face. I like to modulate the Size of Galaxy module to create basically an equivalent of distant crash sound.
Well, I just checked the docs and indeed, you note “do not modulate” and might actually “fix” it if you figure out how! xD
I am sure that it’d “break” a few of my patches (like this one, see around 00:20 I disconnect the Size input and you can hear the difference). However, I also think that it shouldn’t affect your decision whether to change that behavior or not!
I wondered if anyone would do that on purpose… and now I know at least one person does! Cool.
OK, this is a great example of how plugin developers should approach this. Suppose I figure out a way to make the static-crash sound disappear when you change the SIZE knob in Galaxy. Here is what I would do:
Add a new option to turn the anti-crash ability on and off.
When creating a new Galaxy instance in a patch, default to turning the crash effect off. The user can turn it back on if they want, but we assume not making static sounds is “better” for most people, most of the time.
But when loading an older patch where the new option is absent, assume that we should turn OFF the anti-crash instead of using it. This is the backward compatibility part. It means any old patches will still behave the same way they did before updating the plugin.
This example is just for explanation. In fact, I have not figured out a way to eliminate the crash sound when the size knob is changed, nor am I likely to anytime soon. When I studied the Airwindows Galactic algorithm (of which Sapphire Galaxy is a clone), the static sound when you change the size is intertwined with the amazing level of optimization the author Chris Johnson achieved for this reverb. I just can’t figure out a way to tease them apart.
In general though, I do everything in my power not to break backward compatibility for patches. If I have released a Sapphire plugin version, it means I am committed to preserving all the quirks of its audio output in future versions when loading older patches. Any new features or changes in behavior must be opted in manually by the user, inside that older patch, so that older patches still work by default.
I advocate that other plugin developers follow this idea too. I’m sure many already do.
I mean, yours is a great approach. But imagine that 99% of musicians except that one guy hate the zipping noise, yet all of them would encounter it and have to switch it off every time! I think for me it would be a paralyzing feeling, to make sure module is all sorts of perfect before it is released.
As software developers we know that perfect software is not possible, and in context where imperfections may be desirable to some this means any change warrants a new option every time, which eventually can overwhelm GUI and make it cumbersome.
Hardware modular doesn’t really have an equivalent need due to its drawbacks. It doesn’t scale, you buy a module and that’s it. In some cases you can update firmware, and then you have a slightly different module, but you usually don’t care because you can’t really auto-recall all settings with as much precision as what we have in VCV.
In software land, I think any extension mechanism usually acquires the functionality for managing/pinning versions at some point.
Of course, there is also added the complexity, which VCV may understandably want to avoid, so I get it. However, if VCV wants to encourage the core spirit of modular, unconventional connections and turning bugs into features, in contrast to regular DAW’s limited “just use as intended” approach, then I think the added complexity would be worth it.
Just for clarification, the hypothetical approach I outlined would not require this. After upgrading the plugin, if you create a new patch, any new behavior deemed “better than” the old way, would become the new default. For example, an old patch would still make zipper noise, but a new patch would not. You could manually change the setting in either case to make it do the opposite.
OK, by that logic module updates would break patches, so we are back at the initial example: someone’s bug is another’s feature (imagine if the split is not 99% vs. 1% but 70% vs. 30%).
Of course, affected musicians could take measures to flip the switch if it is mentioned in release notes, but that both 1) puts pressure on plugin devs (some very nice modules don’t have almost any docs, much less a changelog) and 2) relates to an adjacent missing feature in VCV: supporting changelog metadata for versions and exposing it when bumping a package—currently it’s a binary “update or don’t” menu item.