How do you deal with updating your plugin when it's not backwards compatible?


#1

I’d like various versions of my plugin to be able to coexist in the same computer / project / whatever, so that people can load projects with older versions of the plugin easily.

I am updating PrettyScope. The Plugin Code i use is PrSc. I am thinking of upticking a number moving forward. PrS2, PrS3, etc. every time the plugin is updated where it’s not backwards compatible.

But then what if i get to 10? the code is only up to 4 characters.

I could do Pr01…Pr25

Anyone have a better idea or is this idea already of sound mind?


#2

It really depends on the plug-in. however, imagine each time Apple, Google or Microsoft “upgrade” their OS you’ll need to wipe your data. no upgrade path.

That’s exactly what you’re doing. someone had a session, now the session won’t load anymore.

It’s not that hard to allow updates if you take some considerations.

  • if your current version don’t take care of future versions it might be at least fair to identify old “legacy” settings and handle it differently, notify the user that after saving the project it won’t be compatible with older versions.

  • use solutions such as free data-structures (xml, json) like AudioProcessorValueTree where your state is saved with a structure you can always add, modify or remove keys and even change range (so if you got -20 dBFS value within range of -40 to +40 you can decide next version that you go to -80 - 80 it won’t break old presets). only issue that won’t be robust is host automation…

  • make your current version expect future versions…
    I basically add a revision field to the state. this allows us to:

    • migrate between versions if needed.
    • show an alertbox if the user trying to load newer state on older version (so he’ll know it won’t load properly).

Some companies did new versions with different Ids. from user POV this is frustrating. There’s nothing like opening old project you suddenly need to discover you’ve used Plugin v1 on your G5 that won’t load on Plugin v2 with your current setup.


#3

This issue can be mitigated if, for example,

  • the older version allows the current setting to be exported, and the newer allows it to be imported.

or

  • the two versions share a common “area” where presets are stored (a directory, a database)

In either case, it is possible for a user that has both versions installed to migrate a session from using the older to the newer, by saving/exporting the current setting with the older instance, replace it with the newer and then load/import those settings back in.

This procedure is time consuming and, as I said, it is only a mitigation of the problem.


#4

You have some good points but from my experience.

  • Older version DOES allows exporting, but imagine your project was saved with a PPC product. there’s no way you’d run it on any x86 from the past 7 years… (so yes, you could’ve saved them then, just as you could print those tracks processed).

  • This is nice, also Pro Tools (AAX/RTAS api) supports legacy Ids so you could migrate to newer one. Again, if the past you (we’re talking about musicians and sound engineers…) didn’t properly save the state then. you might be out of luck.


#5

I have the same problem after moving away from another framework, so for the future versions of my plugins, I will have this kind of support.
The idea, I add an integer at the beginning of the chunk which indicates the version number. The writer would be simple, but the loader has to understand all the previous versions and sets up the parameters to match what it should be.
Of course, if it’s not possible, then maybe you want to create a new plugin altogether!


#6

Backwards compatibility is a difficult and under-appreciated facet of plug-in development. Getting it right involves pre-planning and a lot of testing.

Just one comment on adding a version to your saved state:

While it’s not necessarily supported by the JUCE wrappers, there is already a chunk version in the specs for AU (see kVersionString in AUBase::SaveState() and AUBase::RestoreState()), VST (see AEffect::version and discussion at Juce, Projucer and VST Version / Vendor Version) and AAX (see AAX_CChunkDataParser::mChunkVersion). Given there is already a lot of confusion about differences between the plug-in version and the chunk version, you probably don’t want to have your own third preset version that is independent of those other two.