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

[David Robillard]

On Tue, 2020-07-14 at 18:24 +0200, Bent Bisballe Nyeng wrote:
> 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)

In the long term I think a good dynamic data mechanism, for things like
this, to replace dyn-manifest, and many other things, would be a very
good addition, but that's quite the project.

More pragmatically, I think you could pull most of this off with
LV2_Options_Interface, which lets you say stuff about ports (among
other things).  In this case, you want to change the lv2:name.  What's
current missing is a way to notify the host that something has changed
that it might be interested in.

Adding API for that seems like a threading nightmare, so I'm not sure
how that would work.  The easy solution, I suppose, would be to send a
message about it, and let the host retrieve things when/how it wants,
if it cares?

Cheers,

-- 
dr