[Feature Request / Bug] Super large MIDI's make browser tab run out of memory

[Andrew-J-Larson]

I propose the fix to this to be a better means of playing the files...

Maybe in some sort of buffer chunks?

Where it loads in the songs in chunks, and unloads the parts already played?

[grimmdude]

Thanks for reporting this. This is a known architectural limitation — the library parses all events upfront and keeps them in memory for the lifetime of the Player instance. Here's what's happening and what would need to change:

Why large files cause memory issues

1. Full upfront parsing — dryRun() parses every event in the file into JavaScript objects before playback begins. A single MIDI "Note On" is 3 bytes on disk but becomes a JS object (~200-400 bytes in V8) after parsing — roughly a 100x memory expansion.
2. Nothing is released — The raw file buffer, all parsed event objects, and track data are retained for the entire Player lifecycle. Events that have already been played are still held in memory to support seeking (skipToTick()).

A 1 MB MIDI file can realistically produce 20-40 MB of heap from parsed events alone.

What a fix would require

There are a few possible approaches, each with trade-offs:

• Release the raw buffer after parsing — Setting this.buffer = null after dryRun() would free the raw bytes since they're no longer needed. Low-risk but only addresses a fraction of the memory usage.
• Streaming/lazy parsing — Parse events from raw bytes in real time during playback instead of all upfront. This would eliminate the track.events array but would break skipToTick(), totalTicks, and tempo map building, which all require a full parse pass.
• Event compaction during playback — Release events behind the playback head as they're emitted. This would steadily reclaim memory but would break backward seeking.
• Typed arrays for event storage — Encode event data into typed arrays (e.g., Float64Array for ticks, Int32Array for note numbers) instead of individual JS objects, which would significantly reduce per-event overhead.

Any meaningful fix beyond releasing the raw buffer would be a significant architectural change. Keeping this open as a known limitation for now.