Since 0.7.8 AAP makes use of AAPXS SysEx8 as extension controllers, and that means we made MIDI ports mandatory to exist. However, we still populate ports via port elements in aap_metadata.xml if exists, and if they do not name MIDI2 input and/or output ports, AAPXS SysEx8 messaging is lost and it even causes unwanted blocking.
Creating MIDI ports is definitely the only solution, but what makes it problematic is how we determine if the plugin "accepts MIDI inputs" and "produces MIDI outputs" (in JUCE terminology). We need to make them identifying whether they are also used by the plugin code, not just AAPXS.
Current idea for the decision process:
if there are the declared ports, and if there is no MIDI input or output, then AAP creates "System MIDI In" or "System MIDI Out", then those names could be used to identify if it was not created for user code.
If there is no declared port, then AAP hosting reference implementation automatically creates them.
If the category is Instrument then it has an ordinary MIDI input port. There will be always System MIDI Out port.
If the category is not, then it only populates System MIDI ports.
Since 0.7.8 AAP makes use of AAPXS SysEx8 as extension controllers, and that means we made MIDI ports mandatory to exist. However, we still populate ports via port elements in
aap_metadata.xmlif exists, and if they do not name MIDI2 input and/or output ports, AAPXS SysEx8 messaging is lost and it even causes unwanted blocking.Creating MIDI ports is definitely the only solution, but what makes it problematic is how we determine if the plugin "accepts MIDI inputs" and "produces MIDI outputs" (in JUCE terminology). We need to make them identifying whether they are also used by the plugin code, not just AAPXS.
Current idea for the decision process:
categoryisInstrumentthen it has an ordinary MIDI input port. There will be always System MIDI Out port.categoryis not, then it only populates System MIDI ports.