Hi Tom, 2018-04-23 19:25 GMT+02:00 Tom M. <tom.m...@googlemail.com>:
> I keep thinking about this preloading feature and I'm not yet fully > convinced of it. I see quite high obstacles for it being beneficial i.e.: > > - We need a user who plays MIDI files via command line and listens to them > in real-time. > - The user must actively enable on demand sample loading > - The MIDI file(s) must make use of on-the-fly program changes (because > only then hearable sound interrupts will occur) > Yes, preloading of samples for MIDI playback is only useful for MIDI files containing program changes. I don't know for sure, but my guess is that it's not uncommon for MIDI files to contain multiple program changes on a single channel. So assuming we want to support those MIDI files with dynamic sample loading, preloading of the samples is absolutely necessary to not mess up with the playback timing. And from reading some of the responses to this thread, resource limited environments are quite common. Just consider the Andoird case, where somebody uses libfluidsynth to create a MIDI player app. Phones would benefit a lot from having reduced memory consumption. And not just with >1GB Soundfonts. And it's not just memory consumption. I've tested the preloading with the FluidR3_GM.sf3 file from the MuseScore project. Uncompressing all samples in that Soundfont takes a lot of time, even on my fast laptop. With dynamic sample loading and without preloading, MIDI files with quick program changes do sound wrong when played with that SF3 font, as uncompressing even a single preset takes such a long time. With the preloading, you get the best of both worlds: much faster loading time but still seamless MIDI playback. > So, do we need sample preloading? > I must admit that I don't really have a need for the feature myself. But I do feel that it complements dynamic sample loading nicely and makes it usable in more scenarios. And I've actually just finished an implementation of it: https://github.com/FluidSynth/fluidsynth/pull/371 So maybe you/we can have a look at the changes and decide if the feature is worth the added code and complexity. I'm fine either way. Cheers, Marcus
_______________________________________________ fluid-dev mailing list fluid-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/fluid-dev
