midi 2.0 - midi-CI

[TheTechnobear]

(this is spawned off request #40 , as i think its a separate but interesting discussion item)

Perhaps Electra ONE could start to make use of new MIDI 2.0 features?

In particular MIDI-CI is all about 'synths' describing their parameters to 'interested' midi applications.
This sounds to me alot like what Electra One is doing with EIF.

Obviously MIDI-CI is new, and not a lot of support at present, but it will grow with time.

so perhaps Electra one should consider:

Is EIF needed? or could something based off of MIDI-CI be adopted, so its more 'standard'

I can see reasons EIF might still be needed including

• midi-ci too 'heavy' for embedded use.
• midi-ci not containing enough information, we need more.

in both cases, I see two principles...
EIF should be made to be easily convertible to/from MIDI-CI, (import/export)
if it is a 'superset' of midi-ci, then midi-ci could be use to provide the 'starting' point for an EIF.

advantages for Electra One:
as MIDI CI/2.0 grows

• many users will be looking for devices that support it... being an early adopter could bring in alot of interest to E1
• midi 2.0 devices will 'automatically' be usable by electra one, without additional mapping.
• perhap E1 could become a kind of 'bridge' for midi 1.0 devices to midi 2.0 hosts
  (i.e. E1 adds the 'metadata' mapping for midi 1.0 devices, so that it can publish midi-ci on its behalf)

of course, I recognise, theres a lot of work already gone into EIF etc - and its already a working format.
so I guess, my suggestion is a review of MIDI-CI and Electra One to see how the furure might converge , and what benefits that might bring to Electra One?

[TheTechnobear]

for completeness...
https://www.midi.org/midi-articles/details-about-midi-2-0-midi-ci-profiles-and-property-exchange

oh, also as a bit of background, I know that BomeBox are talking about making thier devices into this kind of midi 2.0 <-> midi 1.0 bridge .

also just to be clear, midi 2.0 is backwards compatible to midi 1.0.
the idea here is primarily to 'enhance' old midi 1.0 devices that will never see midi 2.0 implementations, and use a bridge that will add midi-ci (using some kind of 'instrument profile') to that midi 1.0 device.

[christofmuc]

@TheTechnobear I can clearly see the MIDI 2.0 CI and Property Exchange become standard, even if I feel it is a bit heavy-weight and very inspired by the typical HTTP protocol used by the rest of the planet (e.g. "status: 200", lol).

But am I wrong or is no dedicated standard profile yet published? They reference a "VA synthesizer" profile, but that doesn't really make sense, does it? It's VA, so it could be used for an Analog Synth as well, and they all have very different parameter sets.

I tried to work through the MIDI 2.0 specification, and there is a lot about the transport protocol down to the bit level and compression schemes prescribed, but not much about the semantic content transported. And there is the "X-" resource, which immediately again opens the door for manufacturer-specific stuff which is non-standard. I might be missing something, it is my first deeper contact with MIDI 2.0.

[TheTechnobear]

I can't say I've look at the full details of the Midi 2.0 spec, ive not had a project yet that requires it.

but, not quite sure I follow.... publishing meta data pre-dates http/internet by a long time ;)
sure its using json, but really thats just because json has in many areas replaced xml (which would have been the other natural choice)

of course, the starting point has to be transport/protocol, i.e. how to get the meta data from enquierer to responder

as for MIDI-CI and semantic description.
it needs to (and does) support both generic meta data, and define some common ones.
e.g.
you'll see that MPE cabability, or things like 'local on/off' have been published as specific resouce capabilties.

(here some of the published specs in this area : https://www.midi.org/specifications/midi-2-0-specifications/property-exchange-specifications)

this generic parameters are mostly required for 'controlling' aspects e.g. know what midi channels to use/are available, or how to voice things, or turning on/off certain instrument features.

however, you don't need this for every possible instrument parameter... as it implies the 'controller' is going to need to do something specific with this info. e.g. you cannot and do not need this for all synth parameters ( 1 )

in these cases, we deal with them generically, as a user just wants to see the parameters description, or a host wants to give a descriptive name for automation - we already have this in the Plugins world, AU/VSTs publish whatever parameters they like - and this works pretty well, and MIDI-CI seems to build upon this.

anyway, as I said, Ive not really researched this thoroughly, but I definitely see this as a great opportunity for Electra One.

as I mentioned two main uses:

• editor: the user can simply plug in a midi-ci capable device. and the E1 editor could show parameters available, with ranges, so the user simply is dragging this onto the UI as needed.
  (really it eliminates the instrument def side)
• enhance E1 to be a midi-ci enabler
  this is almost the opposite, take the current instrument defs that the E1 knows about, and publish these to enquirers about connected devices... this is what I believe bomebox plan to do.

I will say i don't underestimate the effort in this area....
one fear I have of midi 2.0 is the complexity of it, esp. in an area that many are frankly not that interested in tech/protocols etc.

I remember when CORBA was introduced, and many thought it would be used for everywhere to help reduce the number of propriatary protocols in use ... alot of ambition. whilst it was (very) successful in many areas, for many it was just too complex (like midi 2.0, had huge numbers of docs, and annexes), some implemented the basics... others just waited for something simpler to come along... which is why http/xml/json became more popular - it was simpler ;)

---

(1) in many ways this is the failing of Midi 1.0, trying to use specific ccs for particular purposes. simply because more complex synths needed parameters that could never be codified. e.g. a particular synth might need 'Waveshape Envelope 3 Decay'
so, only a few of the MIDI CC parameters ever really 'stuck' (e.g. CC 7 = volume)

[christofmuc]

but, not quite sure I follow.... publishing meta data pre-dates http/internet by a long time ;)
sure its using json, but really thats just because json has in many areas replaced xml (which would have been the other natural choice)

I really just meant that they introduced a "status 200" in the protocol, which is really a code defined by HTTP. No big deal.

you'll see that MPE cabability, or things like 'local on/off' have been published as specific resouce capabilties.

(here some of the published specs in this area : https://www.midi.org/specifications/midi-2-0-specifications/property-exchange-specifications)

Ah thank you, I didn't find these links! So there is the concrete semantic for program lists (aka bank dumps). i guess this is the list to grow, e.g. adding specific controller information. I see only Local On/Local Off specified here.

however, you don't need this for every possible instrument parameter... as it implies the 'controller' is going to need to do something specific with this info. e.g. you cannot and do not need this for all synth parameters ( 1 )

in these cases, we deal with them generically, as a user just wants to see the parameters description, or a host wants to give a descriptive name for automation - we already have this in the Plugins world, AU/VSTs publish whatever parameters they like - and this works pretty well, and MIDI-CI seems to build upon this.

I agree this is main bang for the buck - if the MIDI-CI profile would contain all the data currently in the IDL file, setting up an editor for a device would be easy, as you mentioned in use case 1.

as I mentioned two main uses:

* editor: the user can simply plug in a midi-ci capable device. and the E1 editor could show parameters available, with ranges, so the user simply is dragging this onto the UI as needed.
  (really it eliminates the instrument def side)

Yep, sounds great. I haven't seen the specs though for the "reflection" on the properties. Normally you just need to do something like "list of properties", and for each property like type, min/max value or allowed values in an enum, etc. A pretty simple description. Not sure if there is a profile already that does this.

* enhance E1 to be a midi-ci enabler
  this is almost the opposite, take the current instrument defs that the E1 knows about, and publish these to enquirers about connected devices... this is what I believe bomebox plan to do.

Understand. I'd rather suggest to use my software, the KnobKraft, than the E1 as there we make generic synth drivers in Python that don't depend on KnobKraft at all. Basically these are just python files which follow a certain convention ("duck-typing"), and you could run them in any environment which has a Python interpret to transform higher level calls into sysex bytes for our lovely vintage devices.

I will say i don't underestimate the effort in this area....
one fear I have of midi 2.0 is the complexity of it, esp. in an area that many are frankly not that interested in tech/protocols etc.

Ah, same here. I have done quite a lot of Web Software though, and if there are libraries for MIDI 2.0 which make this about as convenient as consuming REST APIs - and I think that should be possible - it will be possible to do. It has a certain committee smell, though.

I remember when CORBA was introduced, and many thought it would be used for everywhere to help reduce the number of propriatary protocols in use ... alot of ambition. whilst it was (very) successful in many areas, for many it was just too complex (like midi 2.0, had huge numbers of docs, and annexes), some implemented the basics... others just waited for something simpler to come along... which is why http/xml/json became more popular - it was simpler ;)

Oh yes! But then, if you develop for Protobuf or Flatbuffers, you're back in the whole header generation techology we though we left behind, there certainly are applications where this is a useful technology.

(1) in many ways this is the failing of Midi 1.0, trying to use specific ccs for particular purposes. simply because more complex synths needed parameters that could never be codified. e.g. a particular synth might need 'Waveshape Envelope 3 Decay'
so, only a few of the MIDI CC parameters ever really 'stuck' (e.g. CC 7 = volume)

Indeed, they couldn't envision a K5000 back then ;)

It'll be interesting to see when and if the MIDI 2.0 gets momentum from device manufactures. I'm willing to do use case 2, but only if JUCE supports MIDI 2.0 properly or some other library comes up, I'm certainly staying away from implementing those protocols myself.