I thought of a way to do what I need, without relying on the deprecated ModuleWidget::fromJson():
- Choose an old param to use as a “sentinel” param.
- Create a new param identical to the old one, and move all uses of the old param to the new one, leaving the old param unused.
- In the module constructor, give the old param a “sentinel” value that was not possible in old presets.
- This is Squinky’s trick, with a twist: Rather than adding a new param to use as the sentinel, co-opt an old param. That way, when an old preset is loaded, it overwrites the sentinel param with a non-sentinel value. A new preset will have the sentinel value. An old preset will not.
- Start
process()by checking the sentinel param. If its value is not the sentinel, we must have just loaded an old preset, so migrate the params.
I don’t like this, because contorts my module in a few ways. First, it wastes a param, and uses the param for a responsibility that really has nothing to do with parameters. Second, process() has to do stuff that is none of its business, and on every single sample it must account for an event that happens very rarely, and that would better be handled as an event.
But I dislike it less than creating a new module every time I think of new features that require migrating old presets… especially when I know exactly how to migrate old presets to take advantage of the new features.
I haven’t decided yet: Which do I dislike least? Using deprecated behavior, or contorting my module to put responsibilities where they don’t belong?