Re: [fluid-dev] Proposal for a new feature: lazy-loading of SoundFonts

[Philippe Simons]

Hi all,

So I think I'm probably the best placed to speak since I'm using fluidsynth both as a MIDI player and as a real-time synthesizer on Android.

Obviously I didn't wait for this feature to be implemented to create my applications, so I can say that I don't them... like at all.

for the player, I didn't tried 1GB SoundFont, but honest quality SoundFonts like Arachno and Fluid R3 works great and deliver a so much better sounds that the internal Android MIDI player, or other player I found on the Google Playe Store.

for the real-time synthesizer, again I didn't tried 1GB SoundFonts, but with a decent device (3-4GB RAM) I don't see why it shouldn't works...

And also, frankly, having a portable SoundFont MIDI synthesizer is awesome, but if you are really into that kind of stuff, the audio output quality of Android devices is not that great... and you need a real computer...with a real soundcard.

Anyway, I think dynamic sample loading is a great feature for device where memory is really an issue like embedded MCU etc...

just my two cents

Philippe

On Tue, Apr 24, 2018 at 9:01 PM, Marcus Weseloh <address@hidden> wrote:

Hi Tom,

yes, it's a little hackish... but not the part you mention, I think. Overriding the "authority" of the synth over when and which samples to load is perfectly valid, in my opinion. Yes, those functions would also need to be exposed to the user via the shell and API, but that would actually be quite trivial. They would only be thin wrappers that would retrieve a preset by sfont id, bank and program and then set or unset the loaded_manually flag and potentially unload the preset.

What I think is really hackish is the way my implementation needs to go through the MIDI file and "play" all program change and bank change events on the actual synth instance, saving the state before doing so and resetting it after. But it was either that, or recreate a lot of logic from the program change mechanics in the player. Not pretty eiher way.

So all in all I agree, let's tackle this problem if and when somebody actually needs it.

I keep the PR open for a few days, maybe someone on this list will want to try it out. If nobody speaks up, I'll close it beginning of next week.

Still, it was interesting to implement it. I got to know the player a little more :-)

Cheers,

    Marcus

_______________________________________________
fluid-dev mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/fluid-dev