[sdiy] MIDI parser

Tue Nov 14 08:38:13 CET 2017

Horses for courses.
I guess it depends on what you're end goal is.

I've written MIDI parsers for AVR (Monowave being my first) and several 
things since. But these days I'd rather spend time on the thing I'm 
making and use code already proven for things like MIDI :)

in much the same way as if I was using USB, I wouldn't write my own USB 
handler, I'd use a known good stack :)

Paula

On 2017-11-14 01:55, Stephen Davies wrote:
> Hi Dave,
> have implemented my own MIDI parsers on AVR, Tiva and Microblaze.
> 
> I’m with Brian, building your own parser is a great way to get to the
> heart of MIDI.
> 
> Two big ‘gotcha’ moments for me were:
> 1) realising that real time messages can be sent in the middle of other 
> messages
> 2) learning about “running status”
> 
> Have fun,
> Stephen
> 
>> On 14 Nov 2017, at 8:51 am, rsdio at audiobanshee.com wrote:
>> 
>> Hi Dave,
>> 
>> Since you want to learn how to manipulate the data yourself, I 
>> encourage you to write your own MIDI parser. Start with the official 
>> MIDI standard, and pay careful attention to the full documentation. 
>> Then be sure to test thoroughly. There are plenty of 
>> potentially-confusing details, but working through those will teach 
>> you a lot about MIDI, and I believe that is well worth the effort.
>> 
>> I start writing MIDI code on 8-bit processors in 1984, so perhaps I am 
>> biased. I've also seen a few outright errors in open source MIDI 
>> parsers (but the example that I remember was USB-MIDI, not classic 
>> MIDI). I won't say that I don't still make mistakes in new code, but I 
>> like having more options. Having made a couple of mistakes along the 
>> way, I now have a much improved ability to diagnose MIDI problems.
>> 
>> For simple applications, using a library is fine. However, there are a 
>> few applications where having your own parser will be advantageous. I 
>> assume that most libraries deliver complete messages, rather than 
>> allowing your code a change to react to each individual byte. This is 
>> certainly true of CoreMIDI, but that's a lot higher level than an 
>> Arduino MIDI library.
>> 
>> If you want to create a MIDI merge function, then having your own 
>> parser is great for low latency. I created a Hammond drawbar MIDI 
>> controller that also had to merge data from a MIDI keyboard. 
>> Obviously, it makes the most sense to give priority to the Note 
>> messages over the CC messages. My dual input MIDI parser allowed a CC 
>> message to be interrupted in the middle by a Note coming from the 
>> other input, just to make sure that there was minimal delay or latency 
>> on the MIDI Notes. My merger does this without dropping any CC 
>> messages, but by having a slightly different parser for each input 
>> with appropriate priority tuning.
>> 
>> If you're controlling an analog synth engine from a ATMega, probably 
>> with DAC outputs for each CV, then your parser could do things like 
>> set the VCO frequency CV before the MIDI Note message has even 
>> finished, so long as the VCA is silent at the time, and then when the 
>> Velocity byte comes in your code can modify the CV outputs for the 
>> Envelope(s) and VCA, along with any other velocity-dependent 
>> parameters. That little head start on the VCO frequency CV could 
>> seriously reduce the latency of your MIDI synth. The same might be 
>> true for pure software synthesis, although there aren't as many delays 
>> to worry about when you don't have analog circuits fed sequentially 
>> through D/A conversion latencies.
>> 
>> If you're interpreting MIDI System Real Time messages, then writing 
>> your own parser could seriously tighten up your timing. Of course, 
>> it's possible that the standard libraries have efficient callbacks for 
>> this, but there's no guarantee. If you're merging System Real Time 
>> messages, then I highly doubt that a stock library will have the 
>> minimal latency. The MIDI protocol was actually designed specifically 
>> for 8-bit processors to allow minimal latency parsing.
>> 
>> You also have the option of leaving out the pieces of the parser that 
>> deal with messages that you don't want to handle. That's not really an 
>> advantage in itself, except that it can reduce the amount of code that 
>> you have to review and test.
>> 
>> Anyway, if you choose to write your own MIDI parser, then good luck! I 
>> hope you enjoy the process and learn a lot. Don't forget the official 
>> MIDI spec as the best source of answers to most of the questions 
>> you'll have.
>> 
>> Brian Willoughby
>> Sound Consulting
>> 
>> 
>> On Nov 13, 2017, at 11:13 AM, "Dave Magnuson" <abide at dmdrafting.com> 
>> wrote:
>>> My reason for trying it myself is the sheer number of “MIDI.H” 
>>> libraries out there – and of course not all of them are compatible 
>>> with each other ;)
>>> 
>>> But point taken – maybe I will reconsider the stock Arduino library 
>>> if self-coding seems like a nightmare
>>> 
>>> Thanks Paula!
>>> 
>>> 
>>> Sent: Monday, November 13, 2017 1:52 PM
>>> To: Dave Magnuson
>>> Cc: synth-diy at synth-diy.org
>>> Subject: Re: [sdiy] MIDI parser
>>> 
>>> Dave,
>>> 
>>> MIDI is a complete nightmare to work with. You'll end up with a 
>>> complex state machine, it's really not worth writing your own 
>>> handler, the Arduino one is (from what I've seen) very well written.
>>> 
>>> Paula
>>> 
>>> On 2017-11-13 18:18, Dave Magnuson wrote:
>>>> Hi All,
>>>> 
>>>> I’m just beginning to experiment with an Atmega-based Arduino Mega 
>>>> 2560, programming it through the Arduino IDE.
>>>> 
>>>> I’ve done all of my various “Hello World” examples, played around 
>>>> with encoders and lcds, etc .   Now I  want to delve into MIDI.  I 
>>>> was wondering if anyone has any C-based MIDI parsers or other 
>>>> examples they would be willing to share?
>>>> 
>>>> I’d rather avoid using the standard MIDI.H library so I can learn 
>>>> how to manipulate the data myself.
>>>> 
>>>> I’ll probably begin with a MIDI monitor / filter or something 
>>>> simple, then probably a MIDI to drum trigger / clock module
>>>> 
>>>> Any links or references would be greatly appreciated
>>>> 
>>>> Dave Magnuson
>>> 
>> 
>> _______________________________________________
>> Synth-diy mailing list
>> Synth-diy at synth-diy.org
>> http://synth-diy.org/mailman/listinfo/synth-diy
>> 
> 
> 
> _______________________________________________
> Synth-diy mailing list
> Synth-diy at synth-diy.org
> http://synth-diy.org/mailman/listinfo/synth-diy