[sdiy] MIDI parser

Stephen Davies davo2002 at tpg.com.au
Tue Nov 14 02:55:03 CET 2017


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
> 





More information about the Synth-diy mailing list