Is the order of parameters returned by AudioProcessor::getParameters guaranteed to stay consistent?

While implementing some unit tests, there was a team internal discussion wether or not we can expect the order of the parameters in the array returned by AudioProcessor::getParameters to stay consistent over JUCE releases? Is there some guarantee if the parameter layout of the plugin doesn’t change, that the order of the parameters stays consistent forever across every JUCE version or can the order change at any time?

Would be great if this could be reflected in the documentation of the function in some way.

I sure hope it would never change, because that would break automation compatibility in hosts that use their index for automated parameters. That requirement is one reason we’ve never re-ordered our parameters (unless we were intentionally breaking backwards compatibility anyway).

@HowardAntares I was under the assumption that the value returned by AudioProcessorParameter::getParameterIndex is the “real” index to be used. But if I get you right that we can always assume the return value of that function to match the index in the array returned by AudioProcessor::getParameters? Or speaking in code

auto& params = myProcessor.getParameters();

for (int i = 0; i < params.size(); ++i)
{
    jassert (params[i]-> getParameterIndex() == i);
}

From looking into the code it seems they never change. The juce::Array flatParameterList is never sorted and only addParameter appends values.

The getParameterIndex() is important if you work with the setParameterTree().

Thanks for looking at the implementation, @Daniel. Still, this is not really the proof I want to rely on since in theory, the implementation is allowed to completely change if it still shows the documented behaviour. Especially as something like version hints for parameters (discussed here) seems to be added in near future, I don’t think it’s a completely unrealistic scenario that the behaviour of this implementation might change at some points for whatever reasons. I’m not saying that particularly the version hint thing will change this – this should only support my point that the parameter handling is a part of the interface that won’t ever be touched again.

As the expected order of parameters in this array isn’t documented anywhere, changing the order could not be considered a breaking change. So what I’d ideally like would be a clear documentation, stating what and what not to expect.