One of the main reasons I originally embraced Audio Units almost twenty years ago was its parameter scheme. E.g. one could extend the range of integer parameters without breaking backward compatibility - because they weren't normalised. This has become deeply embedded in my company culture. One could say "this is what we do", as we maintain plug-ins such as MFM over the years by adding little new things.u-u-u wrote: Mon Dec 20, 2021 1:40 am Also how to solve the problem of backwards compability for a stepped parameter?
E.g. a "Band type" parameter of an EQ plugin. If a value option is added or the order changes between two versions of a plugin there could be a mechanism which maps the old indices to the new indices. This way the host could adapt its automation curve accordingly.
Afaiaa the plug-in standards that have strictly normalised parameter ranges have never added any workarounds to compensate for such changes in plug-ins. It's a bit as if that's something "plug-ins maybe shouldn't do", and because they're all controlled by host developers, it may be a bit "let's keep it that way".
Which is another reason for our decision to promote CLAP: As plug-in developers we always feel like our products are second-class citizens in the DAW ecosystem, as if the plug-in standard forms a harness of what we can do and what we can't do. As someone expresses it so nicely, "as if the host puts its fingers into the plug-in and directs it". CLAP feels a lot more on equal level, which is already expressed by having a host object and a plug-in object. The host isn't a shapeless god entity, it's just another struct that we communicate with.
I think for stepped parameters there could be a fallback value for deleted list entries (a remapping from old to new values). For continuous parameters it should be a bit harder because the parameter(s) of a nonlinear automation would have to be designed in a way that they can adopt to a curve split so that each resulting segment still can be represented by the same amount of parameters. Almost every daw has this issue when moving time selections of automation when they split curved segments. The mathematical solution isn't trivial, I guess.
i'm just a bit curious what these projects might be and how such an integration could generally look like - not expecting anything production ready. but i'm absolutely not in a hurry and can wait, too