[LV2] Proposal: Extension for dnamic port annotations/decorations (ie. display names)

[Bent Bisballe Nyeng]

Hi list

Over the last couple of years a particular subject has kept popping up
in the DrumGizmo community: "Can we have port names inside the DAW named
after the channel-names from the drumkit for easier channel creation?".
So far the answer has been a "no", since altering the port names after
plugin load might interfere with the channel mapping/audio graph inside
the DAW and as such would not work.

Ideally what I would propose (and has propsed previously) would work
someting like the midnam extension, where the plugin can report changes
to the channel names as they occur and the DAW can reflect them in the UI.
We have this working with jack, where the portnames are named after the
channel names in the loaded drumkit, which only works because the
drumkit is loaded from the commandline argument and therefore known
before the jack client is even started.

My proposal: Add another "layer" of metadata information to the
channels, used only for displaying to the user in the port matrix, and
not interfering with the connections.
This means that the channel count must be known from the manifest as
normal as well as the channel type, index, symbol and name.
On top of this a displayname can dynamically be reported using an update
callback like with the midnam extension.
This would make it possible to show the portr names in the channel
mapper (for example in Ardour
https://www.libremusicproduction.com/sites/default/files/tutorials/12_dg_routing.png)
instead of just numbers using the annotation names.
It might also be possible for the DAW to use these names (if present)
for channel fan-out if done later than plugin insertion (where the kit
has not yet been loaded).

Down the road I imagine that other annotations could be added as well,
like for example icons/images or an overload indicator which could
dynamically change at runtime depending on the channel data - but all
still optional display annotations and no semantic information that
needs to be used for the audio graphs.

What do you think? Would it make sense to implement such an API from the
host perspective, and could you as a plugin developer think of other
cool stuff that this could be used for? (or some reasons why this whole
idea is just the worst you have ever heard of :-p)

Cheers // Bent