Documentation of Editor Protocol

[Joris]

Hi Blokas,

Great release of great product! Thanks!

Question:
Will the editor protocol (SysEx I presume) be documented?
Does the device respond to these messages on other ports then USB 5?

Cheers!

PS I’m one of the ‘super early bird’ customers

[Giedrius]

Hey! Thank you!

The communication is currently in SysEx, the 5th reserved USB port is used entirely for the communication, the other 4 ports are used only for musical data.

We will be looking at using COM / CDC instead for communication, this way the programming MIDI port won’t appear in audio software, resulting in smoother user experience.

We don’t plan to document the protocol we use, as it would require additional maintenance and support, we’d rather focus on making the editor as good as it can be.

[Joris]

Hi @Giedrius,

Thanks for your reply.

Because of so many possible gear setups, I’m into automating (scripting) a lot of it, and Midihub could play a crucial role in that. I was hoping for a public SysEx description, like the iConnectMIDI4+ (which is indeed controlled by SysEx).

Would another solution, to allow automatically generated setups, be a possibility for Midihub in the future?

The file format of Midihub seems binary, a text based file format would also be really helpful.

I hope my urge for something that can be generated by software other than the accompanying editor comes across.

Cheers!

[Stephen]

Hello,

I just started playing with the editor before considering buying the Midihub.
As @Joris I’m considering automation and an open protocol through sysex would be very convenient.
I understand your point about the potential confusion of having that additional control midi port.
But maybe it is a tiny problem regarding the great potential for automation or any future use cases ?
For sure there is that support issue…
Anyway, I just wanted to “+1” the interest for an open protocol

[Joris]

Hi @Giedrius,

Please keep your SysEx approach, not only because of automation, but also because I foresee that using COM /CDC means that Midihub needs to be connected directly to a computer, and no other system like iConnectMDID4+ can sit in-between, right?
I would like to have Midihub work on the USB Host port of iConnectMDID4+ (with allows class-compliant MIDI devices).

Hope that your production-line is ramping up, now that you had a 1000% plus campaign (congrats!). Can’t wait to get mine…

[Giedrius]

Thank you!

A composite device can still be class compliant in all interfaces it provides, I have already tried this out on a couple of phones, they see Midihub correctly, and not having the 5th MIDI port, dedicated for communication with the editor, should provide for a smoother user experience.

[Joris]

Hi @Giedrius,

So you are saying that Midihub would work & be editable via your software when I have it connected via a iConnectMIDI4+ host port? Are you sure? My understanding is that anything besides class compliant MIDI will be terminated there and then. This is also what one typically sees with devices (say) from NI which do more than MIDI (Komplete Series Keyboards). If those are connected to the USB Host port of a iConnectMIDI4+ there MIDI part functions fine, anything else does not. So it renders the Komplete integration useless and makes those controllers ‘dumb’ (only MIDI). (Please understand, the iConnectMIDI4+ is more than a USB Hub, it is also a USB Host and MIDI DIN router). The computer does not ‘see’ the connected USB devices, but has MIDI access. That is why I am pressing for keeping SysEx as a communication protocol.

Cheers,
Joris

[Giedrius]

A USB device can have multiple interfaces and still be class compliant. I don’t think it’s the issue of the devices connected to iConnectMIDI4+, rather it seems iConnectMIDI4+ is misbehaving being a USB hub then.

[Joris]

A USB device can have multiple interfaces and still be class compliant.

Yes, I’m aware of that.

… it seems iConnectMIDI4+ is misbehaving being a USB hub then.

It is not misbehaving, it is by design as it IS not a USB hub, but more a MIDI router that works in DAW-less setups, and as such hosts USB devices, and routing MIDI from and to them, but only MIDI. Please consult the the specs here if you want: here

So, please allow for these remote kind of setups by having a SysEx protocol (like you seem to have now), instead of local (to computer) only setups.

Cheers,
Joris

[thetechnobear]

my personal opinion…

although I generally don’t like, closed protocols, I agree supporting an api can be a drain on development resources - so, even though I’m a developer, I’m with @Giedrius, its much better concentrating dev effort on editor which 99% of users are going to use.

perhaps a compromise…
not supporting this kind of usage (so keeping dev effort on editor), but perhaps just open up a small ‘crack’ for the adventurous

perhaps access to the sysex, and a human readable form (json?) of setups could be a compromise - that’s is ‘unsupported’, so use ‘as-is’, undocumented.
(this is not uncommon, many things you can ‘hack’ setups, but the company does not document/support this usage)

I’d agree sysex is useful as it’ll pass thru midi routers and also if we have the option to receive/transmit it to port 5, then this gives options like using sysex librarian - and also an option for send/recall on things like a rPI where the editor is not available.

port 5 is a bit confusing, but I think its not too bad… as it doesn’t appear in the editor.
(guess it just has to be in the manual somewhere?)

---

another alternative, perhaps later - open source the editor and firmware of midihub?
that way users with different requirements could modify to their requirements on their own (at their own risk of bricking the midihub)

this would also allow the adventurous (developer) access to the binary protocol via the source code, should they wish - but its then not an official api, so doesn’t need to be ‘supported’