Hi all,
thank you very much for your feedback! Good to know that there is interest for this feature outside of my particular use-case.
I've decided to go the route Tom suggested: concentrating on the samples first and leaving the "structural" information loading unchanged for now. That will bring the most immediate benefit. And if the structural information loading is still a problem, we can tackle that another way.
I have already implemented a test version of this lazy (or smart :-) sample loading by simply doing it when a preset is selected from a Soundfont via fluid_sfont_t::get_preset. That obviously has the drawback that the Fluidsynth API stays locked during loading, but leads to an extremely simple implementation. The audio rendering code doesn't seem to acquire any API locks, so there shouldn't be any audio dropouts due to the API lock being held for too long. And I just noticed: Soundfont loading is currently done under the API lock as well! So there's no need for an additional thread, it seems.
Does anybody see a drawback in doing the lazy sample loading in-thread under the API lock?
Cheers,
Marcus