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?

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

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

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 🙂

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.

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.

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

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.