The idea here is something more general than MIDI. MIDI has only 127 CC numbers, and we must map these manually. This made sense when in the early days of MIDI they were trying to cram everything into a 7-bit protocol travelling over a 35kbaud serial link. With modern CPUs and software, it makes more sense to use 32bit words for everything. (I know MIDI 2 goes towards this, but it has many things we don't need.)
The idea, part of a personal project I call Hedgehog, is to use a simpler and richer language, based on 32bit words.
- Each parameter of a plugin should have a numerical address.
- There should then be a map of names to addresses.
- Each controllable parameter should receive one of a small number of messages:
- Change to (normalised): a value in the range 0.0..1.0.
- Change by (normalised): a value in the range -1.0..1.0 that is added to the normalised value.
- Addresses can be thought of like IPv4 addresses: as dotted-quads like 192.168.1.45. The 0.x.y.z range would be reserved for common addresses.
- There should be some common addresses for things like filter cutoff and such: those settings which turn up on synth after synth. Then we can send the same 'change filter cutoff by +5%' message to any synth to do the same thing.
This much could be implemented in a DAW without modification to plugins: a track carries Hedgehog messages, alongside audio and midi. These would be translated into parameter changes when they reach their target plugin.
Something similar should happen for per-note parameters (like MPE). Anything that is per note, like frequency, or panning, should be able to be controlled by messages. (This is something that would require support in the plugin interface.)
In addition, when it comes to automation, having a standardised format for storing/loading automation curves, so that they can be moved between DAW's easily, and also possibly modified/generated by external scripts. Like drawing API's have generally converged on the Postscript model of moveto-lineto-fill etc. There are only a small number of possible things we want to do with automation curves.