My experience of providing backwards compatibility for presets

Post Reply
User avatar
AndyMac
Posts: 152
Joined: Wed Sep 05, 2018 6:16 pm
Location: Wirral UK
Contact:

My experience of providing backwards compatibility for presets

Post by AndyMac »

In case anyone is interested, I spent quite a lot of time getting an approach to backwards compatibility of presets as I update/enhance modules and I thought my approach could be of interest to others:

The basis of my backwards compatibility handling is storing a major (internal) version of the module in any saved presets/variations. I use a static for the current "Module Preset Version" (the current internal version of the module) which is added to the presdet as a byte in the GetStateInformation routine. The internal version number, which only needs to change if there is something needing backwards compatibility such as changes to switches from 2 to 3 or more pole, additional switches which need to be in a specific state for older presets, etc.

As SetStateInformation (to get any additional information from a preset when loaded) only gets called if there is some additional data in the preset, Cherry Audio added the notifications Preset_Loading_Start and Preset_Loading_End notifications (and the more recent Variation versions of these) which are always fired when a preset is loaded (including loading state in a DAW).

To catch old presets that weren't saved with a version number, a Boolean "Preset Loading" value is set (for safety in my logic) and the "Preset Loaded Version" value is set to 0. If the preset does have a version, then SetStateInformation gets this and replaces the Preset Loaded Version with the new value. When the Preset_Loading_End notification is fired, it has information that a preset was loaded and the version of the preset, and therefore any specific backwards compatibility work can be done here.

One oddity when doing some more complex backwards compatibility (where controls being visible/enabled depends on jack connections) is that the initial preset loading happens BEFORE the jacks are seen as connected, so I often have to "remember" that there are actions to do which rely on this state information and pick them up on the FIRST run of ProcessSample or ProcessBypassedSample.

I now add the preset version information in all presets saved by my modules so that backwards compatibility is easy to manage going forwards.

Hopefully this makes sense and maybe helpful to other developers.
UrbanCyborg
Posts: 625
Joined: Mon Nov 15, 2021 9:23 pm

Re: My experience of providing backwards compatibility for presets

Post by UrbanCyborg »

It makes sense, and seems a useful approach. I also hadn't known about the relation of preset loading to jack connectivity. Thanks for sharing, Andrew. :D

Reid
Cyberwerks Heavy Industries -- viewforum.php?f=76
User avatar
AndyMac
Posts: 152
Joined: Wed Sep 05, 2018 6:16 pm
Location: Wirral UK
Contact:

Re: My experience of providing backwards compatibility for presets

Post by AndyMac »

No problem, and glad it's useful.

I have also reported the jack state notification timing on load to CA (it actually seems like the jack state notifications get fired multiple times on load), so this may get improved or even resolved in a future version.
Post Reply

Return to “Module Designer”