The MIDI Forum

  1. Andrew
  2. MIDI Specifications
  3. Thursday, 11 August 2016
  4.  Subscribe via email
As part of an upcoming project I needed a generic way to describe Midi Implementations and Sysex in a programmatic way.

To this end I have created a Midi Implementation (JSON) Schema based loosely on the "MIDI Implementation Chart V 2.0"
The idea being that any software (or hardware for that matter) can read these files and know how to manage and talk to your equipment.

You can find an (very) early draft here:
https://github.com/starfishmod/MIDI-Implementations-Schema/blob/master/schema.md

I'm looking for feedback, errors, omissions and obviously contributions to help this become a suitable and usable spec.
In the meantime I am developing tools to help with creating and testing schemas.

The github link is https://github.com/starfishmod/MIDI-Implementations-Schema.


Andrew
Comment
There are no comments made yet.
Accepted Answer Pending Moderation
0
Votes
Undo
How do you handle checksums?
How do you handle memory-like parameter maps (as in GS or XG), where multiple consecutive parameters can be set at once?
Comment
There are no comments made yet.
  1. more than a month ago
  2. MIDI Specifications
  3. # 1
Accepted Answer Pending Moderation
0
Votes
Undo
Good point on checksums, it something I have seen but I don't have a good document to reference. Have you got a device in mind when you are talking about this so I can look at the spec to get a good example? I'm also aware that right now the spec does not support sysex calls with various byte lengths determined by the data itself such as sample loads etc.

I'm not sure about parameter maps as it not something I have come across with my gear. Can you give me an example of what you mean? My google-fu is not getting me any examples.

The Midi Implementation spec does ask if the the device supports General Midi (GM, GM2 and GMLite) and I have put that under https://github.com/starfishmod/MIDI-Implementations-Schema/blob/master/schema.md#fixed-fields-3 (see GM option)
However I might add XG and GS as options as well so that the application should know to support these sets as well.

Thanks for the feedback
Comment
There are no comments made yet.
  1. more than a month ago
  2. MIDI Specifications
  3. # 2
Accepted Answer Pending Moderation
0
Votes
Undo
GS, XG, and many vendor-specific extensions use these features.

For the checksum algorithm, see the XG specification, or the manual of any GS device (e.g., SC-8820).

As for parameter maps, in GS, "master tune" is four bytes at address 40 00 00, and "master volume" is one byte at address 40 00 04. They could be set with two separate data set commands:
F0 41 10 42 12 40 00 00 tt tt tt tt ss F7
F0 41 10 42 12 40 00 04 vv ss F7
But it is also possible to combine them:
F0 41 10 42 12 40 00 00 tt tt tt tt vv ss F7
Comment
There are no comments made yet.
  1. more than a month ago
  2. MIDI Specifications
  3. # 3
Accepted Answer Pending Moderation
0
Votes
Undo
OK I see you point. I'll add in something to handle this in the sysex handling.

Since the MIS that is purely a way to describe how to talk to a device, the assumption is that if the chart->GM settings are set to XG/GS etc that the application should follow all the XG/GS specifications. That being said I'm hoping that either I or someone else would be able to have a public spec that describes this.

The idea being that say something like a Yamaha CS1X* which has the XG spec + it's own extra set of params/sysex. The MIS file would say it has XG, so go reference the XG file and the document would only list the extra information required for the CS1X.

Thanks again :)

* note this is purely off memory and I may be wrong :)
Comment
There are no comments made yet.
  1. more than a month ago
  2. MIDI Specifications
  3. # 4
Accepted Answer Pending Moderation
0
Votes
Undo
hi Andrew,

For the purpose of documenting sysex, I use BNF grammar displayed in railroad format (see attached example)

Here is the source file for this (simplified real case) diagram:
PresetSysEx ::= 'F0' Header (
(kmBruteGetPreset Bank Preset ( '00' | '01' | '02'))
| (kmBruteSetPreset Bank Preset ( '00' Revision Char+ | '01' | '02'))
) 'F7'

Header ::= '00' '20' '6B' '06' '01' '00' PayloadSize


I use this website Railroad Diagram Generator to produce the diagram.

But this is only for documentation, your approach is attacking other problems along mere doc.
Attachments (1)
Comment
There are no comments made yet.
  1. more than a month ago
  2. MIDI Specifications
  3. # 5
Accepted Answer Pending Moderation
0
Votes
Undo
Robert Bocquier wrote:

For the purpose of documenting sysex, I use BNF grammar displayed in railroad format (see attached example)



Interesting where are you using this at the moment? I'm not sure about BNF itself, but it does make me wonder if there is a similar parser for this kind of data already.
Comment
There are no comments made yet.
  1. more than a month ago
  2. MIDI Specifications
  3. # 6
Accepted Answer Pending Moderation
0
Votes
Undo
We started using it as an internal documentation tool at Arturia. This is an experiment.

For parser of this kind of grammar (something we didn't investigate), you have the Lex/yacc family (where yacc stands for "Yet Another Compiler Compiler";) and some more modern derivatives such as ANTLR
Comment
There are no comments made yet.
  1. more than a month ago
  2. MIDI Specifications
  3. # 7
Accepted Answer Pending Moderation
0
Votes
Undo
You could use yacc to write a parser for the MIDI serial bytestream, and it is a good exercise to confirm that the protocol is sensible (if you find yourself using all sorts of weird hacks to get yacc to handle the MIDI protocol then it's a sure sign that there's something wrong in the protocol design), but for practical implementations a hand-written parser is simpler, especially for small embedded 8-bit CPUs. I wrote one a few years ago that handles the full set of MIDI messages, although it could really do with generic handlers for continuous controllers, sample dump, file dump, and so on.
Comment
There are no comments made yet.
  1. more than a month ago
  2. MIDI Specifications
  3. # 8
  • Page :
  • 1


There are no replies made for this post yet.
However, you are not allowed to reply to this post.