I’m in the process of writing a midnam patch definition file.
As I understand it - midnam patch files are structured so that:
A channel list, a controller list and bank definition is contained within a Name Set.
With a bank definition containing the patch list.
Another way: a Name Set defines which patches/banks and controllers are on which channels.
A midnam file can have multiple Name Sets.
For example an external Organ module may have one Name Set for the upper manual with associated patches and controllers on a specific channel. With another Name Set for the lower manual with associated patches and controllers on another channel. With another Name Set for the pedals with associated patches and controllers on yet another channel.
When I try to test my midnam file - Ardour imports it fine. I can add Patch Changes into a MIDI Region but I can only see the Banks & Patches in the first Name Set only.
Am I correct in thinking that Ardour only honors the first Name Set only?
To answer my own question… yes Ardour (kinda) honors multiple NameSets - but with non-intuitive behavior. Whether any PatchBanks in the additional NameSets actually work correctly depends on how the midnam file is structured. More than a few midnam files in Ardour github are affected.
This seems to be down to how Ardour deals with loading midnam files/entries when action’ed. Best shown with screenshots.
With a single NameSet all PatchBanks are shown at first activation.
Only after clicking on the PatchBank does it then show the PatchBank’s in another NameSet.
If you didn’t know this additional NameSet existed - discovering it would be almost impossible.
I don’t know how this will be handled in future versions of Ardour. However, it would be nice to be able to discover PatchBanks in additonal NameSets intuitively. As currently - you have to know they are there to be able to find and use them.
It seems that Ardour does populate the PatchChange Dialog correctly for the first NameSet. However, it populates the PatchChange Dialog incorrectly for any additional NameSets. An example is with the “General MIDI” midnam file.
The first NameSet Patches are populated correctly.
However, an additional NameSet Patch is not populated correctly. Either 127/127 or 0/0 are populated into the Bank MSB and LSB entry boxes. From the midnam file - it should be 0/0 in this case.
needs a bug report at tracker.ardour.org or will be forgotten (and not making any promises that it will be addressed on any particular timeline either). Thanks.
Thanks - I’m still digging into the issue as the structure of the midnam file seems to also have an effect.
If it is allowed - I’ll continue adding what I find here and in the bug report refer back to this thread?
In the case for the MIDI.midnam it contains multiple NameSets. Where the PatchBanks within the different NameSets call out to standalone PatchNameLists outside the ChannelNameSet scope.
Likewise, if I structure my own midnam file in the same way as MIDI.midnam with standalone PatchNameLists outside the ChannelNameSet scope - I see the same issue of incorrectly populated MSB and LSB values.
If I structure the midnam file differently so that all PatchNameLists are within the ChannelNameSet scope with no call outs - I do get correctly populated MSB and LSB values
A temporary solution at the moment for my midnam file is to pull everything into one NameSet and have all PatchLists within that ChannelNameSet scope.
However, there are many midnam files in the Ardour github for Roland/Yamaha/General MIDI that do have this issue where in additional NameSets if the file is structured to call out to a PatchNameList outside the ChannelNameSet scope the incorrect MSB and LSB values are populated.
As requested - I will create a bug report in the tracker.
I’m now convinced that it isn’t a problem with additional ChannelNameSets specifically but a problem with use of UsesPatchNameList where the PatchNameList is outside the NameSet scope.
I have identified that all these midnam files in Ardour’s patchfile directory are affected. I have randomly selected and tested many of these Patch files and they exhibit the same incorrect population of the MSB and LSB values.
Everytime - I try to submit a bug report - I get the following error: "APPLICATION ERROR #27
You have reached the allowed activity limit of 10 events within the last 3600 seconds; your action has been blocked to avoid spam, please try again later."
Even if I leave it for a day between visits - I still get the error.
