On 16 April 2018 at 05:18, Marcus Weseloh <mweselo...@gmail.com> wrote:
> Hi all, > > I've finished the first draft of the dynamic sample loading. You can see > the change in this pull request: > https://github.com/FluidSynth/fluidsynth/pull/366 > > If you want to try out the changes, please check out the > dynamic-sample-loading branch: > https://github.com/FluidSynth/fluidsynth/tree/dynamic-sample-loading > > The implementation is actually quite simple and follows the approach that > I've outlined earlier. When loading a Soundfont, everything apart from the > sample data is loaded. As soon as a preset is selected for a channel, all > samples of all instrument zones in that preset are individually loaded into > memory. And when a preset is unselected again, all samples of all > instrument zones of that preset are unloaded from memory again, unless they > are still in use by another selected preset. The loading and unloading is > triggered by the fluid_preset_t::notify and fluid_sample_t::notify > callbacks. > I am not using midi instruments + fluidsynth in a live performance setting, but if I was I would want to make damn sure that changing instrument mid-song happens promptly *100%* of the time, and is not sensitive to unpredictable I/O times or process scheduling issues. ie. there's a hard realtime requirement here in some usages - is it still possible to meet that requirement with the samples being loaded/unloaded? I'm not a midi expert so please forgive the vagueness of the question. From what you've written I guess the performer can setup presets for all required instruments and then switch between them without any loading having to take place? That seems ok to me, but is perhaps still surprising to a performer who is used to everything being available once the soundfont is loaded. To be clear I love the idea of being able to conserve memory by not loading unneeded samples, I just want to make sure it's not coming at the cost of the realtime use case. Cheers, -sqweek
_______________________________________________ fluid-dev mailing list fluid-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/fluid-dev
