Black MIDI Wiki
Advertisement
mmidi (Multimedia MIDI) is a collective word for a line of midi players and other midi-related tools which were developed with Black MIDIs in focus.

Players[]

The mmidi line consists mostly out of multiple editions of mutations and rewrites.

To preserve performance (the main goal of this entire lineup), each feature set requires a separate exe, as runtime feature selection significantly degrades the performance when it comes to handling hundred-thousands of notes per second.

mmidi[]

The original mmidi program was originally just a console-based midi player, whose name comes from the mmidi library which it is based on.

Just before the visualizer was added, the mmopt branch was created for slightly increased performance over the visuals.

This edition is no longer maintained other than bugfixes. Supports KDMAPI, ModMSG, and WinMM.

mmopt[]

This is just mmidi with the visualizer stripped and the code reorganized to perform better. Prints text to the console instead of to the top of the screen, like in the original mmidi.

This edition is no longer maintained. Only supports WinMM with DeviceID being hardcoded to 1.

mmm[]

mmm, or as named in the "branding" text MorshuMidi is a complete rewrite which came 2 months after the initial mmidi release, focusing on lowering the CPU cycles per note as much as possible, thus having extremely high note bandwidth, higher than all other available midi players.

This edition has no visualizer, nor does it print any text to the console other than the "branding" text to decrease the wasted processing power and also make the exe smaller.

This edition is under active development. Only supports KDMAPI.

mmm-mmidi[]

mmm-mmidi, or as alternatively named mmmmidi or Morshu-mmidi is a branch of mmm with mmidi's visualizer merged into the code.

This edition is under active development. Only supports KDMAPI, and the benchmark editions support SendCustomEvent.

mmvis[]

mmvis is the latest derivation of the mmidi line. It's derived from mmm-mmidi. The reason for this derivation is seemingly unnecessary, but it was done for adding more features at the cost of highly decreasing its performance (but still higher than all other known MIDI players).

There are numerous versions of this floating around the internet, some including different combinations of these features:

  • A new method of mixing the notes in the visualizer which can be identified by overlapping notes appearing very bright, and NoteOffs causing weird colors not in the default 256 palette. This feature was scrapped for a higher quality method.
  • A notes/second counter. This feature consumes exactly 156250 Kilobytes (or around 152.5 Megabytes) of RAM per second counted. Note that it counts "played" seconds, not real-time seconds.
  • A note counter.
  • A file open dialog. There is no need to drag midi files on the exe.
  • QPC timer support. It was scrapped due to buggy CPU timers, and the current timer is much more reliable.
  • A true per-note visualizer. There should no longer be holes in the visualizer where they shouldn't be.

Due to the new features causing an unknown crash on some Windows 10 installations, this is the very first edition to include a crash handler. With the exception handler installed it would not crash for some reason.

There are two versions, one using SendDirectData, and one using SendCustomEvent. Due to both versions including the exception handler, these binaries are bigger than all other editions.

MIDI interface support[]

There are multiple interfaces the mmidi line of programs support.

WinMM[]

This should go without saying. Editions without mouse support have DeviceID hardcoded to 1. Everything other than mmopt should try DeviceID 0 and the MIDI Mapper as a fallback before completely failing.

KDMAPI[]

KDMAPI (Keppy's Direct MIDI API, or formerly known as KSDAPI, or erroneously as KSDirect by older mmidi versions) is the interface which is preferred to be used for very good performance by bypassing WinMM. Unless you don't want automatic noteskip, this is the "de facto" interface to use for fast playback.

ModMSG[]

ModMSG is just the shortand for modMessage (MIDI Output Device Message), which is the function used for interfacing with the MIDI output device, ranging from initialization to data processing.

While calling modMessage directly is slightly faster than using midiOutShortMsg, most software synthesizers don't benefit from this "hack".

SendCustomEvent[]

This is the latest addition in OmniMIDI 6.0.57 CR9 requested by the developer of mmidi to bypass most of the buffering and decoding and call into the underlying BASSMIDI, eliminating the need to have the MIDI event to be decoded twice, thus increasing the performance even more.

This is only useful for developers if they already have the MIDI event decoded and processed (in this case by Morshu-mmidi's visualizer), and don't want it to be decoded twice by BASSMIDI's slow event decoder. The same version of OmniMIDI first including this function is using a more optimized event decoder, thus rendering this function kinda useless for those who just want to pass an event to the synthesizer, in which case they should just use SendDirectDataNoBuf instead.

Software synthesizer support[]

Name Interface Symptoms
OmniMIDI KDMAPI or

SendCustomEvent

none, perfect playback, "de facto" support in mmidi players
TiMidity++ ModMSG eventually skips notes, has random notes, and crashes
VirtualMIDISynth ModMSG just slows down with no noteskip
MSGSWS ModMSG skips notes, eventually only hearing the start of a few notes
CoreAudio MIDI ModMSG skips notes, high stream of notes make the audio completely gone
WinMM WinMM very slow, and thus not recommended for Black MIDI playback

Issues[]

  • When using TiMidity++, using the mouse keys or keyboard shortcuts will cut out audio completely until you reload the entire program.
  • Time will be wasted trying to load the file into RAM, even if it doesn't fit in there.
  • Double-clicking the exe will flash up a console window with the usage instructions instead of waiting for a file input.
  • The CPU will spin out 100% until the synth is ready, thus making the synth take much longer to load on single-core systems (mostly happening on Windows XP systems).
  • Memory-mapped editions have horrible performance due to relying on Windows' file buffering and disk speed, even if the file is already completely preloaded into memory.
  • The adaptive timer is unstable for around one second from the first note, causing a noticeable playback speed fluctuation until it stabilizes. Once stabilized, the playback speed can be modified without destabilizing the timer.
  • Setting the system clock backwards will break the adaptive timer.
  • Setting the system clock forward will cause a noticeable speedup burst, but will stabilize again very quickly because the timer can't be destabilized forwards.
  • When the player is trying to compensate for the lag by disabling some elements of the player, it will also disable the SPACE key, so the only way to kill the notes is by pressing CTRL-C or SHIFT-BREAKand hope that the player is not in the loop of processing few hundred thousand notes. Once one midi tick has passed, then the player will pause.

Advantages/Disadvantages[]

Advantages[]

  • Very fast
  • Very small extra memory footprint (midi file size plus a few kilobytes)
  • Very precise low-latency adaptive playback timer with catch-up cap
  • Memory-mapped versions play the midi instantly regardless of size
  • Memory-mapped versions can play midis bigger than what can fit your RAM
  • Simple to use (drag-and-drop midi on exe to play)
  • Minimalistic and very small (console-based, only a few kilobyte exe size)

Disadvantages[]

  • No file selector
  • Console-based, thus unintuitive for some users
  • Not every version has WinMM support (or very poor support)
  • The visualizer doesn't render on very old Windows versions and macOS
  • So fast that some synthesizers will skip way too many notes
  • Stereo panning control is hardcodedly ignored
  • XG midis are broken due to the pan control being ignored

Trivia[]

  • Early editions of mmidi only used WinMM with a bug in the adaptive timer, so those are unsuitable for Black MIDI playback, and performs even worse than Synthesia.
  • The memory-mapped versions (provided enough pagefile) could technically play even the biggest Black MIDIs without fully loading them into the memory (however performance will be limited by disk access speed, RAM speed, and CPU speed).
  • There is unused code in mmidi (which is optimized away by the compiler) which enables transparency support for Windows 7, including a nice-looking Aero window.
Advertisement