I made a boo boo. Renamed components. How would you deal?

[Dan Korneff]

A few years back I switched from building my projects from the ground up to using a template I created that handles all of my basic needs. I then rebuilt my first plugin using the template and didn't realize that the name scheme I had used for my input/output controls changed along the way from Input_Level to Input_Gain. Now when older users upgrade to the newest version, these settings (obviously) aren't being recalled properly.
Any ideas on an easy way to fix this mistake before I start concocting some multi control broadcaster hack?

[Matt_SF]

@Dan-Korneff You mean that the parameters are not properly recalled when loading/switching presets? In that case you could use mass find/replace with a text editor like sublime. You can search across multiple files and replace all names at once...

[Dan Korneff]

@Matt_SF well, the problem is half of my users are using a version that has a component Input_Level and the other half has Input_Gain, so if I switch back to the old name, the newer users get f&*ked. I need a solution that adds Input_Level back to the project and both Input_Level and Input_Gain controls adjust a single parameter.

[DanH]

@Dan-Korneff Is creating a new plugin not an option? Like 'Plug-InName v2'?

[Dan Korneff]

@DanH I'm currently working on v3 of the plug but it would be nice to have them be backwards compatible.

[d.healey]

@Dan-Korneff That's what the preset handler pre callback is for

[Dan Korneff]

@d-healey That would fix initial recall settings, but what if they automated the parameter?

[d.healey]

@Dan-Korneff automation handler perhaps

[Dan Korneff]

This seems to work:

const var InputTrimKnobs = [
    Content.getComponent("Input Trim"),
    Content.getComponent("Input")
];

const var InputLevel = Synth.getEffect("InputLevel");

inline function inputTrimFunction(component, value)
{
    // Determine knob index
    local index = InputTrimKnobs.indexOf(component);

    // component array index will be 0 or 1
    if (index != -1)
    {
        // Set the gain of InputLevel to the changed knob's value
        InputLevel.setAttribute(InputLevel.Gain, value);

        // Update the other knob to match
        InputTrimKnobs[1 - index].setValue(value);
    }

};

for (itk in InputTrimKnobs)
    itk.setControlCallback(inputTrimFunction);

It creates a new automation lane for the additional knob, but I think I can live with that.

[DanH]

@Dan-Korneff What if the new automation lane means that existing automation lanes no longer match in existing DAW projects? I find it shunts the list dow one, so existing automation ends up controlling something else..

[Dan Korneff]

@DanH In my testing, the original lane it tied to the old parameter "Input" and a new lane is created for "Input Trim" and vice versa.