No, old patches work exactly the same way after an update. Old patches use the old default even with the new plugin (detected by the updated plugin noticing the option is absent from the patch).
Once that old patch is saved again, now it has the option present, but that option has the value that makes it compatible with the older plugin.
But if you use the new plugin to create a new patch, the module gets created with whatever we want the new default value to be.
You get both good things: a better new default, plus same behavior when loading old patches. There really isnât a reason you canât have both. I have done this exact thing and tested it to verify it works, so itâs not just a theory.
Oh, thatâs interesting. This may be an aspect of module development Iâm not familiar with, I thought if you add a feature switch with new default, then patches from pre-switch times will adopt the new default, as if the module was freshly added.
Well, that certainly means that with careful development module authors can avoid breakage to the degree possible.
I did have a case where some module started behaving differently after an update so itâs not just theory either, but itâs been a long time ago since I stopped randomly updating module libraries so I struggle to remember which module that was.
I wouldnât be inclined to call out the author anyway, as the number of software engineers who never ever make mistakes is approximately zero.
OK, now it makes sense why you were thinking that.
It really depends on the plugin developer. If they write the plugin code to do that, thatâs what it will do.
Yes, I appreciate that because those of us releasing free and open source plugins are not getting paid anything but kind words. Many of us are sacrificing valuable hours from our lives to make something that other people can use for free. I do like the appreciation because it is rewarding to think Iâm doing something valuable. I also want candid feedback about anything that could be improved; it is validating also!
Yes, I believe this 100% because we are volunteer developers, developing is hard, testing is boring, and it all takes lots of time we donât have.
To get a little more into the weeds, here is what I would recommend VCV Rack developers do in this situation, in technical detail.
Your module should override onReset, which should set a new option variable to the desired new default value.
Override dataToJson, which is called every time just before a patch is saved to a vcv file. This is your chance to store the value of the new option. This option did not exist in older plugin versions, so the serialized json now has extra content.
Override dataFromJson, which is called every time just after a patch is loaded from a vcv file. This is the non-obvious part. Check to see whether the option you now save in step 2 is actually present in the json. If it is absent, it means an older version of the plugin saved the file. In this case, do whatever makes sense for backward compatibility. If the option is present, use its value, because it came from a new (enough) plugin version.
While Iâm looking forward to @pachdeâs comment on this, @cosinekitty do you have any notes whether it works like that, based on your experience? E.g., is it correct that different modules from the same plugin library are instantiated separately, and as such normally shouldnât break if they are instantiated from different source snapshots (unless I suppose if they use expander mechanism and are purposefully incompatible between versions)?
Iâm not sure Iâm understanding the hypothetical scenario with A, B, C, etc. It does not sound correct though, because of this part:
The issue is that if A and B both belong to plugin X, then X can only be a single version. You canât have two different versions of the same plugin installed simultaneously. Therefore, A and B can never be built from different source commits.
If Iâm misinterpreting the question, please clarify and I will try again.
A plugin is normally a single dynamically-linked library. Modules are not separate binary files. It is technically possible for them to be so, but nobody does that. As I said before, in terms of the binary machine code behind the module, the independence of modules is a visual illusion. Each plugin is normally a monolith.
It is also possible to freeze a module and make improvements in a new module that coexists in the same plugin. This has been done several times, usually making the old module âobsoleteâ and hiding it, so that old patches work, but you canât make new patches using it without doing surgery on the plugin json to un-hide it.
But really â what @cosinekitty says. Versioning and backward compatibility is a challenge to accomplish and a lot of work to get right. Adding the bits of UI to choose whether you get old behavior or new is additional work. Itâs difficult to know whether a given change is something that anyone would even notice or want the ability to change.
The same thing happens in commercial software. I have old Microsoft Word documents and Adobe Photoshop files that donât work right in newer versions, and some donât even open anymore. What many commercial enterprises do to protect the value of assets created in those projects is to keep copies of the software in the same archives as the assets.
When I worked at Microsoft the standard was for a project to keep all the tools used to build the product in the same source control system as the product and never depend on installed versions. It wasnât always the case this was done, but a few lawsuits made not doing so very expensive. This is what must be done to ensure reproducibility (the attribute that youâre looking for).
In both of these cases take note that nobody is expecting the producers of the tools to maintain backward compatibility. Thatâs just the reality of software. Even when a company makes gigantic investments in maintaining backward compatibility (e.g. Microsoft Windows - Office not so much), things still break under change, and another strategy is required if you want reproducibility.
Another strategy is to make sure you save recordings of a patch. This is similar to the strategy of maintaining multiple formats of an asset. e.g. I canât open those old PSDs, but Iâve kept have high-resolution PNGs and PDFs of the images I care about. The latter are standard formats not dependent on a specific software.
Totally true. I think itâs worth pointing out, however, that itâs possible to do it âdecentlyâ, and some devs do put in the (large) effort. To me itâs something that a dev âshouldâ do, if they are intending to make a âquality productâ.
Well, I understand the current technical implementation limiting the plugin library to only one version, but I was curious about instantiation at runtime. Perhaps this is something more to VCV core devs than module authors. Appreciated the response!
Absolutely true. Itâs just I was hoping for the modular approach to remove this sort of legacy constraint. In my mind, I saw modules as their own separate things that only communicate through a strictly defined cable interface[0], and therefore can easily coexist when instantiated from different code snapshots.
Massively appreciated the response nevertheless!
[0] Aside from perhaps the expander mechanism, where they naturally might have shared memory and therefore be incompatible across versions.
I found a version of vcv rack 1 that has alot fewer modules that has vst support. I am under the impression it will never be updated again so it might help a little if it has something you want to use. I havenât used it to much but did download and brought it up on my system.
I have a plugin that completely relies on plugins being monolithic. The modules are a tightly coupled suite, and donât use the Rack message passing. it would be much more difficult and maybe not possible to create if modules were separate DLLs.
Of course, my plugin is not a traditional modular kind of thing - itâs an external hardware controller embedded in Rack to get the benefit of rich CV control of the numerous parameters (havenât counted them up, but more than 100).
This is technically possible, and plugin developers have everything they need to implement it. Itâs not something that Rack can do on behalf of plugins or to enforce.
As a practical matter, it can be a challenging endeavor to maintain for an arguably small return. Often you discover the need for it only after youâve released an update. As a consequence, few plugin authors take the extra care and write the extra code and logic to maintain backward compatibility.