the old control ports which take a float pointer and plugins need to read from it every run (including to see if it changed compared to previous runs)
the new patch/parameter style of controls, which are changed via patch:Set messages on the plugin atom port. they take a bit longer to setup, but provide sample-accurate parameter changes and event notifications (you no longer need to check every run if params changed or not, you simply get an event when they do)
because there were 0 plugins making use of patch parameters when we did the v1.10 update (that introduced support for them), we did not bother with the mapping implementation as it was kinda pointless (and hard to test anyhow)
of all plugins that got published into the (stable) store previously, only the “notes” one made use of patch parameters. and well… it is still not that useful to map “notes” font size to a hw control
so parameter mapping was simply not implemented, in a kinda chicken-egg problem where we first needed a couple of plugins to justify the time spent working on the feature.
it is a bit more complex.
although there are some entry points that can be reused for changing value from HMI / mod-ui side, things are a bit more complex because mod-host also allows value changes from control chain and MIDI mappings.
doing it for HMI side is easy, but the other 2 not so much (MIDI events in particular happen during audio thread, so no allocations there). we need to take special care in regards to thread-safety and race conditions when parameters can be changed from different sources.
also we need to be aware of the file format used to save these mappings.
changes need to be made such that it is both forward and backwards compatible. That is, any new data written on newly saved PBs does not break existing v1.10/11/12 users, and old pedalboards being resaved keep working without losing data.