I have created a new MIDI format to overcome both the limitations of the current one and the unwillingness of the International MIDI Consortium to develop a MIDI 2.0 file format. So I made my own for my game engine. I even added some primitive scripting features.

But here comes the big problem: now I need to develop an editor. While I created a textual representation of it, which is a weird mix of assembly with Lua influences and essentially musical notes and rhythm as values, but eventually it should have a full GUI editor.

The format so far has the following kind of commands:

  • Flow control commands
  • MIDI emit commands which can be either:
    • Note on and off commands
    • Velocity change (aftertouch)
    • Program change
    • Control change
    • Pitch bend
    • A few other less important commands (SysEx, etc.)
  • Commands for the scripting (Arithmetic commands on writable registers, compare and branch, etc.)
  • The ever important wait command, on which the whole system depends, as it tells the sequencer how much clock cycles have to wait between two commands

I have to process these commands for two display widgets, one displays the notes in a piano roll format, one displays any other commands. However, thanks to the way things work, I usually cannot just process MIDI commands directly. For example, notes are defined by a note-on and note-off event (often with aftertouch), no duration. And then comes editing. And then comes to editing around various wait commands. And then comes to editing around various conditional jump commands.

I started to work on a system that converted and separated each command for display, but it’s a bit time consuming, and adds extra complexity. But modifying it a bit and adding a “transpiler” to the two systems would make editing pretty easy to implement. I already added “macro”-like features to the textual representation of the format. Could this work?

  • ZILtoid1991@lemmy.worldOP
    0·
    1 month ago

    Basically by transpiling, I’m converting commands to a format with absolute time position rather than the current relative one, so I don’t have to deal too much with the relative wait commands, seeking would be easier to implement rather than one using relative positions, and I wouldn’t really have the issue with inserting extra commands when relative jump commands exist. As I said, the textual format already have some macros that function in similar vein, such as the [0]: note 0 0x7FFF s.:a-5 macro, that automatically inserts noteon and noteoff commands at the appropriate places when processed, and also jump commands use labels similar to some unstructured programming stuff.

    I think I’ll try to work on a game for a while, then peek into someone else’s code that had similar problems on how they actually did it.

    As for the MIDI 1.0 limitations:

    • More than 16 channel implementation is a bit tricky, and I really didn’t want the composer to rely on automatic polyphony handling real time (which would likely conflict with sound effects, etc.), nor wanted to deal with that too on top of everything else.
    • Precision issues with Control Change commands, and I wanted most if not all things to be controlled via MIDI easily rather than aggressive preset swapping or SysEx commands. Some special functionality still uses SysEx, like global waveform changing in the FM synth, where you basically command to change one of the 128 possible waveforms to be changed to a custom parameter-generated one. The only thing that cannot be done from MIDI is specifying path for files, which is intentional since it would mess with real-time features.
    • Adaptive soundtracks. To my knowledge, there’s not a whole lot of formats for this, let alone ones that are known to be open, and even then many don’t go much farther than maybe mixing a few extra tracks they can swap-in, mute, etc., while mine could manipulate instrument parameters, pitch, etc. Instead of going the route of downloading easymp3playback.dll and easymp3playback.h (originally I used sdl-audio), I went with my own audio solution, and since my engine already was custom tailored for “retro pixelart”, I doubled down in that direction, and went with a pretty lo-fi sampler and an FM synth so far.