A way to save old modules?

Hi, as some developers delete some of their old modules (Which is understandable), old patches do not work anymore which sucks. Is there any way to implement a feature where as you save the preset, the modules are also saved within the save file?

I understand there will be repercussions to this - maybe there could be another folder inside of Rack where the data of the modules you downloaded is saved?

The exact feature you want doesn’t exist, but you can keep copies of versions of plugins, so that in a pinch you can use an older version of a plugin temporarily, if you really need to.

  • Open the HOME/Documents/Rack2/plugins/ directory on your computer.
  • Next time you do library updates in Rack, let it download the updates and press Ok to close Rack, but hold off on starting it again.
  • In the HOME/Documents/Rack2/plugins/ directory directory you’ll notice the *.vcvplugin files it has downloaded, including version number. You can now copy those files to a seperate archive directory to have a copy of previous versions of plugins.
  • If you want to have a copy of all the plugins you are currently subscribed to in the library, you could close Rack, and remove all the directories of those plugins under HOME/Documents/Rack2/plugins/ and then start Rack again. Now it will download all the *.vcvplugin files of all your subscribed plugins, and you can copy them to another directory.

It would be interesting to know how many modules were removed since Rack V2 was published.

For plugins/modules that haven’t been ported so far, I keep an inatllation of Rack V1.1.6 on my system.

One thing this thread and a similar thread here Can a patch embed modules ? tells me, not to remove modules from my plugin because I think they are obsolete. Best practice should be to never remove a module.


I agree. I suppose when there is a major VCV version change, and porting all the modules becomes a burden, then it can be understood why some obscure modules could be dropped. But I generally don’t understand why anyone would drop a module within a given rack major version. Deprecation makes sense when a module has a faulty design, and is replaced by something better. After a while the deprecated module might be removed. But keeping it around “just in case” seems the better option to me.

One thing I don’t know is if there is any detriment to a plugin becoming overly large (too many modules). But if that becomes an issue, then why not start a new plugin, rather than throw away existing modules?

1 Like

I don’t think there is an issue. the code is pretty small anyway, and typically (at least for me) a lot of the modules use the same underlying code/libraries, so each additional module doesn’t add a whole lot of new code.