AudioUnit wrapper issue with discrete parameters

We have an AudioUnit plugin that is behaving badly at initialization time. The issue is caused by this code in the wrapper’s addParameters() function:

                for (int i = 0; i < numSteps; ++i)
            {
                auto value = (float) i / maxValue;

                // Once legacy parameters are deprecated this can be replaced by getText
                param->setValue (value);
                stringValues->add (CFStringCreateCopy (nullptr, (param->getCurrentValueAsText().toCFString())));
            }
        }

        param->setValue (initialValue);

The problem arises because several of the parameters are attached to push-style buttons, which trigger a change in our plugin data when set to 1 (pressed). The changes that are triggered are not un-done by the buttons returning to their 0 (unpressed) state. That leaves our plugin no longer in its default state after those parameters have been set to 1, despite the code setting them back to their default (0) states.

Why is this code needed? Why does the AU wrapper need to cycle each discrete parameter through all its possible values? What would happen if we prevented that from happening?

If that code is needed, then how can I restore my plugin to its default state after this wrapper code completes? It seems to happen AFTER the plugin’s constructor runs, so I can’t do anything there to fix this.

Any ideas?

If I comment out that whole section of code where it fills those string arrays, and simply return kAudioUnitErr_InvalidProperty from GetParameterValueStrings(), I don’t see any adverse affects (yet). What problems might this cause, and in which host(s)?

This might show up in things like labels for discrete levels in the automation lanes of Logic.