BREAKING: Re-port MIDI, faster and lower memory, ESP32#790
Merged
earlephilhower merged 3 commits intomasterfrom Oct 21, 2025
Merged
BREAKING: Re-port MIDI, faster and lower memory, ESP32#790earlephilhower merged 3 commits intomasterfrom
earlephilhower merged 3 commits intomasterfrom
Conversation
393e058 to
237cc94
Compare
* Pull untouched upstream TinySoundFont Start from the upstream TinySoundFont by @schellingb at https://github.com/schellingb/TinySoundFont and rearchitect the MIDI processing. * Convert to PROGMEM-based SoundFont structures. This makes it much faster to access the SoundFont and also removes all the static RAM usage. The samples, the regions, the instruments are all now in ROM. Only the dynamic voices and related info takes up RAM. No caching. * (Re)convert to fixed point math. TSF upstream is built for systems with real floating point units (and produces great sound with it!), but processors like the Pico, ESP8266, and several models of ESP32 don't have one so emulate FP in *extremely* slow SW. Use fixed point (integer) represntations for the inner loop and wherever possible to avoid `float` math. For processors like the Pico 2 or original ESP32 with hardware FPUs this still increases performance since integer is still much faster. * Redo the example and add default SF2s Rewrite the 2 MIDI examples to use PROGMEM for both SF2 and MID file. It simplifies life for the casual user and me. * Breaking change The MIDI object now has a `midi::SetSoundFont(tsf *)` instead of a `midi::SetSoundfont(AudioFileSource *)`. It no longer supports reading SF2 from LittleFS or SD.
7ee1896 to
bb6b752
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Start from the upstream TinySoundFont by @schellingb at https://github.com/schellingb/TinySoundFont and rearchitect the MIDI processing.
This makes it much faster to access the SoundFont and also removes all the static RAM usage. The samples, the regions, the instruments are all now in ROM. Only the dynamic voices and related info takes up RAM. No caching.
TSF upstream is built for systems with real floating point units (and produces great sound with it!), but processors like the Pico, ESP8266, and several models of ESP32 don't have one so emulate FP in extremely slow SW. Use fixed point (integer) represntations for the inner loop and wherever possible to avoid
floatmath.For processors like the Pico 2 or original ESP32 with hardware FPUs this still increases performance since integer is still much faster.
The new TSF doesn't hit the compiler bug the earlier version did, so now Xtensa-based ESP32 boards can run MIDI
Rewrite the 2 MIDI examples to use PROGMEM for both SF2 and MID file. It simplifies life for the casual user and me.
The MIDI object now has a
midi::SetSoundFont(tsf *)instead of amidi::SetSoundfont(AudioFileSource *). It no longer supports reading SF2 from LittleFS or SD.