More progress! The three points from the previous post are basically done and things seem to be working well.
The next big hurdle is going to be handling various restart requests from the plugins. VST 3 plugins support dynamically changing various things that are fixed in VST 2. eg: a VST 3 plugin change change it’s number of I/Os, the number of parameters, change the names of parameters etc.
The I/O changes and parameter names changes should be reasonably easy to handle. Changes to the number and types of parameters is a little more tricky. There are various places in Cantabile where parameter information is stored by index (eg: the morph parameter settings, parameter set preset models). If the number of parameters and/or the meaning of parameters at each position is changing then things are going to break.
I think the approach I need to take is to switch from using parameter indices to parameter Ids - and that will need to reflect through to everywhere parameters are used.
So next up to do is:
- Change the API between Cantabile and CantabileCore to better encapsulate parameter details into a more formal structure and do so in a way such that any existing code that uses parameters will fail to build.
- Include a notification in that API to indicate that the parameter set has changed (and invoke it when a plugin says things have changed).
- Review and fix all the deliberately induced build errors so I can be sure that every piece of code that deals with parameters has been updated.
- Make sure everything that needs to respond to changing parameter sets does.
- Find at least one plugin that makes use of all the above and test it.
Step 5 is actually the biggest unknown with all of this: finding plugins that use the various features of VST 3 so I can test things. I’ve posted a question to the VST 3 developer forum hoping to find some good plugins for testing this and other aspects of VST 3.