Original midi2lua (simplified):

events = 
  0, "note", 60, 100,
  480, "note", 64, 100

Patched version (enhanced):

-- configurable time unit: seconds @ 120 BPM, resolution 960 PPQN
events = 
   time = 0.000,   type = "note_on",  ch = 1, note = 60, vel = 100 ,
   time = 0.125,   type = "note_off", ch = 1, note = 60, vel = 0   ,
   time = 0.500,   type = "control",  ch = 1, ctrl = 7,  val = 80  , -- volume
   time = 0.750,   type = "pitch_bend", ch = 1, value = 8192

When midi2lua gets patched by different communities—game devs, chip-music hobbyists, live-coding performers—those patches reflect aesthetic priorities. A live-coder’s fork might emphasize real-time control hooks, exposing functions to mute, transpose, or re-trigger phrases on the fly. A game audio engineer’s fork prioritizes efficient memory use and compact event tables for constrained platforms. An experimental musician’s patch might introduce probabilistic note quantization or subtle pitch drift to emulate analog imperfections.

These divergent goals produce a lively ecosystem: forks that are short bursts of focused utility, others that are sprawling laboratories of musical possibility. Reading through commit logs becomes like sampling different composers’ sketches.

Patching midi2lua is a kind of hands-on composition. You don’t need to be a formal software engineer to start: a curiosity about how MIDI ticks relate to beats, a taste for Lua’s lightweight expressiveness, and an itch to automate or transform are enough. You open the file, read the parser, and you find places that beg for change:

Each patch is a musical decision disguised as code. You’re not only fixing bugs—you’re curating behavior.