LV2 midnam model string is corrupt about avldrums.lv2

[x42]

Also this too, seems there's no extra space inserted for the pointer string,
so it overwrites as seen in the output above

This is intentional. A hack to replace "AVL-Drumkits-LV2" in <Model>AVL-Drumkits-LV2</Model>
with some unique identifier (here based on the instance's memory address).

Since the MIDNAM is unconditionally provided by the plugin, the model-name is not relevant.

[terminator356]

The model name could be important, you never know something might use it.
You could run out of address characters if we ever go to 128-bit platforms, he he.
Anyway I just thought I would mention that it seemed odd it since I noticed DrumGizmo
composes a full string like "DrumGizmo:0x2983e770".
Thanks.

[x42]

128bit pointers will indeed break this current hack :)

I was thinking that when the MIDNAM is provided by the plugin there's no choice: The plugin instance informs the host which model to use, and provides the model. So the model-name can be arbitrary.

I didn't consider that a host might display it regardless.

This is more important for plugins like https://github.com/x42/gmsynth.lv2, drumgizmo or setBfree where the midnam can change, and you can have multiple instances with different models.

If you want to display it, I'd be happy to change this. Maybe even recommend ":" as separator. So a host can display the name up to the colon.

[terminator356]

For MusE no, not terribly urgent at the moment, thanks.
Since the model name is dynamic it would not be useful to store persistently anyway.

Working with midnam for the first time. Interesting.
Would like to provide comprehensive midnam importing.
Read several posts about the birth of the LV2 extension.
Maybe drobilla can come up with a native solution.
(Shortly after I was thinking how unreliable midnam files might be, I read
his blog post saying exactly that - I had to lol. He and the Ardour team
cleaned up so many of them. Amazing work.)

Trying to plan MusE for multiple device modes and per-channel patches/controllers/notes.
Must redesign of our own instrument definition files and editor.
They support a single programmable device mode and patches/controllers/notes,
but are are not per-channel. Although our own MESS framework does in fact
support per-channel stuff such as fluidsynth.
Trying to juggle it all. Cheers!

[x42]

Indeed lots of historical baggage there.

Ardour and Qtractor support MIDNAM for a long time already. One can argue and rant about the spec. Yet it's officially from midi.org after all, and plenty of vendors support it.

Years later plugins like drumgizmo, avldrums came with custom midnam files. A user had to download and install those, and then pick the right one, depending on the plugin preset. So the idea was born to just make this happen automatically.

I disagree with drobilla that LV2 needs a custom spec when there's there's already an established one.

I'm certain that we could come up with a much nicer and more appropriate format and API. But why? Your host will likely want to support midi.org's midnam anyway...

PS. https://github.com/Ardour/ardour/blob/master/libs/plugins/a-fluidsynth.lv2/a-fluidsynth.cc#L811 dynamically creates a midnam for .sf2 files loaded via fluidsynth -- not great not terrible.

[terminator356]

MusE is in a good position to support these dynamically changing midnams.
Our instruments can be easily dynamically changed. I'm looking forward to it.

One thing I should mention is that if there was a dedicated API,
we could ask for specific information such as "give me note name 23",
live in real time without having to cache it.
But when we are given the whole thing at once in an XML format,
we must now cache all that info on our side and sort through it.
That's a lot of info for the host to cache for each plugin, when it is already held within the plugin.
The fact that midnam is popular... seems... irrelevant, not a reason to use it in a plugin.
The plugin designer must now learn midnam and XML just to get what he
already knows into a format the host can read.
Still, I can work with what I'm given ;-)

[terminator356]

I'll close this one up and let you go. Pleasure chatting!
'Til next time.
Tim.