Site navigation

Plugin updates?

Audio Plugins
#1

Hi all,

I’m developing plug-ins that I’m hoping to release commercially in the not-too-distant future and looking into patching/updating. There doesn’t seem to be much out there on this forum, except a very old thread from 2011 suggesting that automatic updating for plugins is complicated and probably not worth it, and that the most robust way to go about product updates is to check the version number against a file on the website backend and then prompt the user with a link to go to a page and download/reinstall the new version manually. JUCE doesn’t seem to provide any modules for this, but I have found the AutoUpdater class that the Jucer uses and given it a glance.

So I’m wondering what solution you/your company have found for this. As a user, I would probably find it slightly annoying to do manual updating and installation, so I’d hate to impose that on my hypothetical customers, but if there isn’t a robust and relatively simple solution, is this OK from a business perspective? I don’t anticipate spending a lot of time adding new features to already-released products but of course want a way to hedge against bugs or perhaps add something if there is popular demand.

Thanks a ton. This forum has been very helpful to me and I appreciate how responsive you all are.

#2

Even if you did automatically update a plugin (my guess is it will be impossible since the DAW may have a handle on one or more files the plugin needs to update) the user would still need to restart the DAW.

We do exactly as you suggested; compare the build version in the plugin against a returned value from website, then prompt the user with release notes and a direct download if they click our “update is available” notification.

1 Like
#3

This is exactly what I do and it seems to work pretty well, none of my users have ever complained about it.

Users likely won’t want your plugin to automatically update if they’re using it on a project since your update could potentially have drastic changes to the sound it outputs. They’d rather know an update is available and go and download it when they’ve finished with that project, or they’re willing to double-check the settings of every instance where they’re using it.

1 Like
#4

Thanks @asimilon, always nice to hear from you.

@ImJimmi Wow I didn’t even think about project compatibility. I imagined re-installing the program would mean overwriting the old version, but now I’m wondering if each version should be a distinct program, i.e., if it should be possible to have multiple versions existing in the user’s plugin folder simultaneously, to ensure that old projects created with the old version of the program remain unchanged without having to worry about backwards compatibility with old presets/DAW automations.

#5

Something I’m planning on adding to my downloads page is an option for users to download a .zip file containing each of the plug-in formats (as apposed to just an installer which I use at the moment) so if users want to have multiple different versions on their machine they can do so (becuase my installer currently overwrites any previous versions it finds).

Only issue with that is that I don’t think any DAWs support having multiple versions of a plug-in so if you have several versions each with the same name, the DAW will presumably choose the most recent version.

#6

@ImJimmi

Well, the name could have the version number in it, like MyPlugin 1.0, MyPlugin 1.1, etc., and then the user would presumably select the latest version on new projects, but keep the old one for compatibility with old projects. The responsibility would be on the user to clear out the versions they don’t want/need, and it could get a little messy (less so for infrequent updates for bugs and major revisions), but then ultimately that gives them control over what versions they keep and if they delete one that turns out to be important, they could then then grab that old version off of your website.

I guess the alternative would be converting presets and automations from old versions to the latest version, and it looks like this can be done by adding the version string as a property in the ValueTree saved in getStateInformation() and setStateInformation() (I’m assuming this is how the DAW remembers settings/automations).

#7

That could be one solution, yeah. Only problem I see with that method is that the DAW will treat each version as a different plug-in and therefore any user-defined presets created through the DAW wouldn’t carry over to new versions.

#8

After a quick test in Reaper is seems is does allow you to have multiple plug-ins with the same name but different versions… only issue being that there’s no indication as to which item in list corresponds to which version.

Capture
This was a quick demo plug-in I made that changed its background colour from red to blue for version 1.0 and 2.0. Reaper shows them both and does let me load either one, but there’s no way to tell which is which (they’re also in reverse order - the most recent version is the one at the top).

#9

Did you use the same Projucer project and just bump the version numbers?

Or did you use different projects with each a unique Plugin Code?

Cubase won’t like the 1st scenario.

#10

What about Plugin Names “RedBlue 1.0” and “RedBlue 2.0” and Plugin Code “RB10” and “RB20” (for example)? Surely the DAW would identify them as unique plugins that way, right?

#11

I changed the version numbers in the Projucer.

#12

By the way, I found on the JUCE: Tutorial: Adding plug-in parameters page (emphasis mine):

Using XML to store the processor’s state

Storing the plug-in state in a binary format results in using less memory and storage space for your plug-in’s state. However, it is often more convient to use a format such as XML or JSON. This makes debugging easier and it also simplifies making the stored state information compatible with future versions of your plug-in. In particular, XML makes it easy to:

  • set parameters not found in the information block to default values
  • include version information in the information block to help handle forwards and backwards compatibility for different versions of your plug-in

It then goes on to talk about setStateInformation() and getStateInformation(), so it seems that adding the version number as a property to the tree and using a function/class to add/modify missing parameters for differing versions would work; the only thing is that I haven’t been able to confirm that this is how the DAW is storing automations (calling get/setStateInformation()), though that would make the most sense I think.

#13

Yep, although I don’t think digits are valid in the plugin code.

I know for a fact that if you have the same Plugin Code in differently named plugins that Cubase only goes on the Plugin Code to differentiate them, so one will be missing.

The DAW is only storing the plugin state with the get/setStateInfo calls, the automation will be stored separately by the DAW. I would hope that the parameter name is what it uses to match the automation when versions change, but to be safe I’ve always added new parameters at the end just in case it’s index based in one of the DAWs.

#14

Hmm, well unless there is a way to ensure backwards compatibility with automations then, personally, I’ll probably go the route of unique plugins (new Plugin Name, new Plugin Code) for each version, and let the user decide how they are going to manage that, and of course allow them to download and install older versions if it turns out they actually need one they thought they didn’t and got rid of. It’s probably better to impose a minor nuisance on everyone than to royally screw someone who lost all their carefully crafted automations after an update. I’m struggling to find info on how DAWs handle automations.

#15

Hi Asimilon! Sorry to bother… I am with some issues with the versión 1.1 of my plugin, it has only a few changes compared to the previous version. What is it suppose to happen when you have one existing saved project in a DAW with a plugin inserted, you download and install the new version and you re-open the project? The new versión would be detected as the same plugin? Because Cubase and Reaper loose the link with the vst and the new version seems to be a different plugin. Is it possible to detect it as a new version and to update/recall the parameters? I don’t use automatization…

#16

In my experience making a new version should just work when you install it, I’ve never run into problems, with either state information propogating or automation. Does the Plugin Code match in the .jucer files?

image

1 Like
#17

YEEEES! Thanks you! The plugin-code was the same but it did not have 4 characters (only two). I completed the name and now It is working. Thanks you!

1 Like