Add an opcode for note names, and API bindings for note and cc names

[paulfd]

@jpcima I'm not super sure about the C API design rules here
@redtide I added an @version tag, is this OK? We'll need to fix it before the release!
@alcomposer you just need to integrate your note name midnam in Ardour now 🙂

• Add and track switch labels and currently switched-on regions

Closes #154

[redtide]

OK to me!

[jpcima]

Perhaps, we should export the library version number; (linked and built against)
for example

https://github.com/Wohlstand/libADLMIDI/blob/a0da4cd2759e1ffeb905b35dc685fd91721b6644/include/adlmidi.h#L671-L686

and

https://github.com/Wohlstand/libADLMIDI/blob/a0da4cd2759e1ffeb905b35dc685fd91721b6644/include/adlmidi.h#L31-L40

[jpcima]

@returns [...] or NULL if the index is out of bounds.

I prefer to avoid specifying this part. The index must be in bounds.

[jpcima]

This might be an incomplete definition of the NoteNameList.

An example from Motif-XF-8

                <ChannelNameSet Name="CP ChannelSet 1" >
                        <PatchBank Name="GM Kit" >
[...]
                                <UsesPatchNameList Name="GM Kit" />
                        </PatchBank>
[...]
                </ChannelNameSet>
[...]
                <PatchNameList Name="GM Kit" >
                        <Patch Number="" Name="Stereo GM Kit" ProgramChange="0" >
                                <UsesNoteNameList Name="SFX Kit" />
                        </Patch>
                </PatchNameList>
[...]
                <NoteNameList Name="SFX Kit" >

[jpcima]

I've added following changes

• rebased on branch develop to eliminate the conflict
• added the last commit which renames label_note to label_key, and associated API and comments
  it's to make it consistent with SFZ terminology in existing opcodes (eg. key, pitch_keycenter, ..)
  @paulfd OK with it?

[paulfd]

Yes no problem, it is more coherent.

@alcomposer I added the keyswitch label if you want to try with your branch!

[jpcima]

With the last addition, do we run the risk that the key could appear multiple times in the list?

[paulfd]

Yes, is it a problem? IIRC the DTD does not enforce unique values for this attribute. We run this risk for repeated label_key or label_cc too btw.

[jpcima]

Then it's no issue, let's validate in Ardour6 and this should be good

[paulfd]

cf https://www.midi.org/dtds/MIDINameDocument10.dtd.html

Note that specifying unique attributes in XML is a bit involved I think, so it might be that they did not want to bother specifying it. However, we may be able to leave it to the host to choose what to do with duplicated notes (e.g. take the last, or take them all). In a way we're passing on the ambiguity from the sfz without committing to a resolution.