But that's my point. Anyone who wants automation to work correctly in Cubase/Nuendo will be forced to change now, because otherwise the missing functionality is not going to be available. Fundamentally I see this as a bug fix, not a feature request. I see it that way because end users will (correctly) expect their automation to work correctly, and they will see it as a bug in my plugin. Other plugin developers will have the same issue unless they implement workarounds. What I'm wondering about is how other plugin developers are addressing this issue.
My functions in my object are not index based. They look something like this.
float MyAudioProcessor::getParameter (int index)
case PARAM_BAND1: return db2normal(m_MemberObject.GetBand1());
case PARAM_BAND2: return db2normal(m_MemberObject.GetBand2());
case PARAM_BAND3: return db2normal(m_MemberObject.GetBand3());
case PARAM_XOVER1: return freq2normal(m_MemberObject.GetXover1());
case PARAM_XOVER2: return freq2normal(m_MemberObject.GetXover2());
Setters work the same way.
void MyAudioProcessor::setParameter (int index, float newValue)
case PARAM_BAND1: m_MemberObject.SetBand1(normal2db(newValue)); break;
case PARAM_BAND2: m_MemberObject.SetBand2(normal2db(newValue)); break;
case PARAM_BAND3: m_MemberObject.SetBand3(normal2db(newValue)); break;
case PARAM_XOVER1: m_MemberObject.SetXover1(normal2freq(newValue)); break;
case PARAM_XOVER2: m_MemberObject.SetXover2(normal2freq(newValue)); break;
This is just an example. There are quite a few other parameters as well. Just passing a reference to an object will not work because I have to call a different accessor for each parameter. With the new architecture I will need to create a new subclass for each parameter and override getParameter, setParameter, etc. for each one, with each calling the correct accessor function.
I could potentially pass a pointer to the object along with a pointer to the member function and use some rather nasty syntax to dereference them, but with all that indirection I would consider it a lot less maintainable than the fairly straightforward code above. There are several other ways to get it done but they all involved helper classes or some other syntactic contrivances and are all not nearly as clean and maintainable as just using switch statements.
I agree that using the AudioProcessorParameter class will reduce coupling and is theoretically "better" from an abstract OO perspective. However, I must also consider the cost tradeoffs involved in rewriting things that are not broken and are currently not creating a problem for me. For me, this rewrite is solving a non-existent problem.
If you are concerned about cluttering the AudioProcessor base class, why not create a separate class for controlling the parameters, something like "AudioProcessorParameterController"? You could simply move all the parameter control methods there and keep them virtual. This would be a much simpler migration for developers who currently use the "index" method (no rewrite necessary, just moving a few functions) and developers who want to use the AudioProcessorParameter class would have that option as well.