A way to save old modules?

Development
1

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?

2

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.
3 Likes
3

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.

3 Likes
4

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
5

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.