anyone support clap_plugin_note_name

[sagantech]

I would like to implement but I need a plug-in to test with. Anyone?

[TaleTN]

Well, I have just added this to my plugin framework, so I guess I could temporarily add this to the next CLAP alpha version of Kee Bass (assuming you can test on Windows or macOS). Would that help?

[sagantech]

It would certainly be a start. I already wrote code to support the dynamic building of a drum set based on the note names. It doesn't sound like Key Bass is a drum plug-in. How would that work for Kee Bass?

[TaleTN]

Well, Kee Bass just returns some strings ("Kee Bass C1..C3" and "Middle C") for notes 48..72. It's not really useful, but it did allow me to test this feature with my framework (IPlug1 fork) in REAPER. Eventually I will remove it again from Kee Bass, but for now I will build a version with this still included.

[sagantech]

I would not mind giving it a try to be sure everything goes as expected. Where can I find it for Windows?

[TaleTN]

Windows:
https://www.martinic.com/files/downloads/kee-bass/Martinic_Kee_Bass_v1.2.0-alpha5.exe

macOS:
https://www.martinic.com/files/downloads/kee-bass/Martinic_Kee_Bass_v1.2.0-alpha5.dmg

[robbert-vdh]

If the plugin does not have a name for a port/key/channel combination then it should just not tell the host about it. Not having note names is the default.

[TaleTN]

If the plugin does not have a name for a port/key/channel combination then it should just not tell the host about it. Not having note names is the default.

Right. However, that's not compatible with my existing framework (I guess originally based on VST 2.4), which doesn't have a count, and just returns false or an empty string for any MIDI note it doesn't have a name for.

I think a host should check for errors on any key regardless of whether the plug-in does the right thing or not. Better to return an error than an empty string. You cannot return a NULL string since the return is not a pointer and the string is already allocated by the host.

Yeah, but if validators are going to fail on this, then it might be better to drop support for this extension (for now anyway).

[robbert-vdh]

Right. However, that's not compatible with my existing framework (I guess originally based on VST 2.4), which doesn't have a count, and just returns false or an empty string for any MIDI note it doesn't have a name for.

I don't see why? If you only have a polling style API available in your framework then just build a list of note names when the plugin initializes (or when this information changes) and use the extension like it was intended to. I'll summarize again, the extension lets the host enumerate a plugin's note names (if it has any), and to which key, channel, and port combinations those note names apply (where -1 for either of those three means 'any').

[TaleTN]

FYI: I have (hopefully) properly solved this by calling my internal get note name for all 128 notes in count(). I also store the successful notes in a small table, so I can I convert from index to note in get(), and again call my internal get note name.

[TaleTN]

If you only have a polling style API available in your framework then just build a list of note names when the plugin initializes (or when this information changes) and use the extension like it was intended to.

I think I've implemented what you suggested, except I'm doing the work in count(), so I only have to do it if the host actually supports and uses the extension. Anyhoo... Thanks! :-)