-
Notifications
You must be signed in to change notification settings - Fork 6
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
midi 2.0 - midi-CI #41
Comments
for completeness... 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. |
@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. |
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 ;) 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. (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:
I will say i don't underestimate the effort in this area.... 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' |
I really just meant that they introduced a "status 200" in the protocol, which is really a code defined by HTTP. No big deal.
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.
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.
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.
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.
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.
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.
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. |
(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
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
(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?
The text was updated successfully, but these errors were encountered: