This is exactly what it sounds like: Code that uses MIDI events to drive the SID chip. Before going any further, however, it should be noted that SIDI is currently a hot mess: Different aspects of it run the gamut from fully tested and known good to shit I banged out just to get something working. It was due for a major refactor but, since the death of my BeagleBone Black necessitated a complete reworking of the management software, it's been sitting on the back burner.
Currently, SIDI only supports the 1 pin to 1 pin method of controlling the SID chip outlined in the MIDI SID Arduino post. The code, however, is structured in such a way that it never writes directly to the chip outside of the SID6581::setAddress() or SID6581::setData() functions, so implementing SPI or a shiftOut() based solution could be done via simple #defines and #ifdef blocks.
Also, it should be noted that, due to following the path of least resistance, SIDI works at 38400bps instead of the 31720 specified by the MIDI standard. For connection to a real-school MIDI bus, one would need to change the baud rate in setup()'s Serial.open to the proper value (as well as build the required optical coupler circuitry, etc). Since we're just using the USB serial from a BeagleBone, 38400 is fine for us.
At present, due to my time being better spent elsewhere, SIDI only supports Note On and Note Off events. While the rough-ins are in place to properly skip events it doesn't understand, I've never tried feeding it MIDI that wasn't filtered through either version of the BeagleBoargan management software first, so if you're using a legit MIDI chain, YMMV.
The sketch itself is quiet simple: The Arduino's loop() function checks if any data's available on the serial port, then receives and inspects the byte so it knows what to do. Events it doesn't understand are skipped, events it does are received and converted in to their SID chip equivalents (ie. Note On is converted to the correct frequency for the voice's Freq registers).
Since the limit on polyphony is much higher in General MIDI than it is on the SID (General midi specifies up to 32 voice polyphony, the SID can only provide 1 voice per channel), a channel operating in default mode will respond to the most recent Note On event received. The firmware does contain some very early (and completely broken) arpeggio support which will cycle through any Note Ons on that instrument which have not received Note Offs. The notes are sorted in ascending order so the end result should sound more musical than simply 5 random-seeming 1/32 notes.
A couple things...
Something else to note before diving in and going totes cray cray is that, while SIDI will receive and function as a General MIDI device, the SID chip's voices are mapped to instruments 1 through 3 so, if you're using the host system's ALSA sequencer to drive it, you'll need to use a player which allows you to remap the MIDI tracks to different instruments as, for example, if Piano is instrument one, SIDI will try to play all notes on the first voice, which probably won't work that well.
The final piece of business before taking a look at this beast is to mention its extensive use of MIDI System Exclusive messages. To keep this post from getting to long, I've created another just for the MIDI SysEx messages SIDI understands. Using this method as opposed to subverting the various controls already in the MIDI specifications, most importantly, ensures an errant piece of automation won't result in, say, an ADSR envelope that doesn't work but also allows us to be a little more efficient in driving the SID-specific portions of SIDI.
The handling of these messages, at time of writing, is where the bulk of SIDI's refactoring is needed as they are interpreted by a switch() statement inside a switch() statement. This maintainability nightmare stems from cowboy coding during the latter stages of the Qt application's development.
SIDI's code, at some point in the forseeable future, will reside here on GitHub. Note that I'm still using Subversion internally and Github's sole purpose is to provide something known to work some semblance of properly, so merging any submitted patches upstream might take some time (although it honestly probably won't).