Bidirectional MIDI (2.0) communication

[ohovers]

MIDI (2.0) allows bidirectional communication.
There are many features in MIDI 2.0 that use this bidirectional communication.
This is allows MIDI controllers to get information about the device they are controlling, e.g. CI data.
I think this could be implemented in CLAP in a very easy way.

Design 1 (simplest):

1. Add a note dialect CLAP_NOTE_DIALECT_MIDI_BIDIRECTIONAL which specifies that bidirectional MIDI communication
   is allowed on that note-port.
2. Specify that bidirectional note ports may not have overlapping port numbers for input/output ports.
   3a) A host may send MIDI (2.0) data to note output ports if the port supports CLAP_NOTE_DIALECT_MIDI_BIDIRECTIONAL.
   3b) A plugin may send MIDI (2.0) data to note input ports if the host supports CLAP_NOTE_DIALECT_MIDI_BIDIRECTIONAL.

Design 2 (allows overlapping port numbers for bidirectional/input output ports):

1. Add a note dialect CLAP_NOTE_DIALECT_MIDI_BIDIRECTIONAL which specifies that bidirectional MIDI communication
   is allowed on that note-port.
2. Add a event types CLAP_EVENT_MIDI_SYSEX_BACK, CLAP_EVENT_MIDI2_BACK (names are just suggestions) that can be used
   by the host to send MIDI data to output ports and the plugin to send MIDI data to input ports.
   3a) A host may send MIDI (2.0) data to note output ports using CLAP_EVENT_MIDI_SYSEX_BACK or CLAP_EVENT_MIDI2_BACK if the port supports CLAP_NOTE_DIALECT_MIDI_BIDIRECTIONAL.
   3b) A plugin may send MIDI (2.0) data to note input ports using CLAP_EVENT_MIDI_SYSEX_BACK or CLAP_EVENT_MIDI2_BACK if the host supports CLAP_NOTE_DIALECT_MIDI_BIDIRECTIONAL.

[baconpaul]

We have input and output queues so I prefer the design pattern where we couple input and output ports. That is you create a pair of note ports then have an extension or attribute for midi2_bidrectional_pair

Note the midi2 in clap right now is just for ump packets basically but geil has thought a lot about the other protocol parts.

Do you have a host or device which can support this? I think most of us are pretty excited for windows m2 support in 2024 and think this will be exciting sruff

[ohovers]

A bidirectional note port for MIDI (2.0) is still either an input or an output port. Not both. The voice messages like NOTE_ON are going one way. Using both an input and output port for this will just confuse users.

It is just that the MIDI (2.0) protocol specifies certain features like Capability Inquiry, Property Exchange, Device Inquiry, Sample Dump, File Dump etc. that need some communication going the other way. Some of these are already in MIDI 1.0 using Sysexes, that is why I am putting 2.0 in parentheses.

Keeping MIDI 2.0 communication at the UMP level like CLAP does is a good design. It is just the UMP part about sending messages the other way that is missing. And I don't think it would be wise to create a new CLAP extension for every bidirectional MIDI feature.

"Do you have a host or device which can support this?"
I don't have a MIDI 2.0 host or device. I am just spouting ideas.

[baconpaul]

Ahh right. So then ignore me a bit :)

So then I am going to claim too much ignorance and ask @Bremmers to hop in. #363 for instance is an example of what he has been thinking.

Anyway like I said: I"m sure this year windows will support Midi 2 properly, as will some more daws, and you will be able to buy a device which sends UMP and supports CI and so on. That will really help but I agree the design groundwork is super important.

[ohovers]

My main objection to using output ports for backwards communication from an import port (and vice versa) is simply that they are called "output ports". If you called them something like "input-reply-ports" (and vice-versa "output-reply-ports") that would make it a lot more clear. The name is not 100% correct, since backwards communication does not need to be in reply to something. But it at least makes it clear to users that an input-reply-port is tied to an input port, and not to expect any note output from it, or that you can redirect it to some other destination.

And you have to add some additional complexity to tie the input-ports and matching input-reply-ports (and also output-ports and output-reply-ports) back together. Complexity that you could avoid by simply making the reply-port implicit when the host declares it supports MIDI_BIDIRECTIONAL and the plugin declares the port as MIDI_BIDIRECTIONAL.

[Bremmers]

Let me start by saying I fully understand why you think bidirectional ports are a good idea. But perhaps this isn't how plugins (of any format) are going to work. Quite a few MIDI-CI features are covered by plugin formats already (state saving, info about parameters etc.). Having two conflicting ways to do the same thing could be problematic. And it could be quite a bit of work for plugin developers to implement all of this. Also, MIDI-CI Property Exchange is a rather inconvenient way to communicate between host and plugin: it's designed for communicating over a cable, so there's handshaking and all that just to get a string value etc.

Some MIDI-CI features don't really apply to plugins. Mentioning Capability Inquiry and Device Inquiry more or less implies you expect plugins to talk to the outside world, behind the DAW's back. That's an exciting idea, but DAW developers may not be keen to allow this. Perhaps plugins aren't going to be full blown "MIDI devices".

There's more to it than just technical preferences: if VST3 and AU don't go this way, DAWs won't go this way either so it's never going to work. It's difficult to decide on something until we know what other formats will do.

In the meantime, MIDI-CI isn't being overlooked. There's an idea for the MIDI-CI Profiles, which Paul mentioned already, for example.

[ohovers]

What you are saying is: Even though a MIDI (2.0) standard exists for all of this, let's not allow developers to freely decide how to apply it for good reasons. Is that not against the basic CLAP philosophy?

https://cleveraudio.org/1-feature-overview/

MIDI Just Works!
Inspired by MPE and MIDI 2.0, CLAP can adapt to any future MIDI standard. Wherever a solid standard exists, we allow developers to freely decide how to apply it. Plug-ins can receive and send any MIDI event on multiple ports.

Also, besides full-featured DAWs there are simple hosts that just forward MIDI traffic. And DAWs are under no obligation to implement any of this. Or they can just filter MIDI traffic, like most of them already do. And if the plugin developer truly wants to bypass the DAW, the plugin can just open the MIDI device itself.

[baconpaul]

Reflecting on that comment, it seems that's written for the protocol not the connectivity - basically a reaction to the pain caused by VST3 not making any MIDI1 information available in the API - but you make an excellent point. With MIDI2 UMP we are totally transparent just like we are with MIDI1. What's the equivalent for the "non-voice" parts of the protocol.