Thanks for the proposal. Let me add my two cents. Memory usage is not only an issue on embedded systems but also for operating systems like Windows. People simply load soundfonts no matter how big they are. The Musyng Kite old soundfont is a very good example. In these days soundfonts of up to the size of 1GB are real. In our app we had to implement a scenario to temporarily unload/reload soundfont when a larger memory portion is temporarily required for another specific action of the app. On the other side the beauty of having all sound samples in one file is that the user does to need to take care of a dedicated soundfont loading e.g. a soundfont for a certain music instrument. However, in most cases only a very small portion of a huge soundfont is really used.
I support having a solution as proposed here but it is important to find a way for scanning and loading of the soundfont not at the expense of the CPU usage for the app e.g. in the background. Reinhold PS: Instead of using the word "lazy" I would vote for the word "smart" :-) -----Ursprüngliche Nachricht----- Von: fluid-dev [mailto:fluid-dev-bounces+reinhold=notation....@nongnu.org] Im Auftrag von Tom M. Gesendet: Dienstag, 3. April 2018 21:13 An: Marcus Weseloh Cc: fluid-dev@nongnu.org Betreff: Re: [fluid-dev] Proposal for a new feature: lazy-loading of SoundFonts So briefly, your main motivation for this feature is memory usage. Absolutely comprehensible on an embedded system. You therefore want to parse only "high-level preset information" of a SF file. I'm missing information about SF2 Instruments here. Counterproposal: Instead of lazy-loading structural information of a SF2, continue to parse all its structural information (i.e. preset, instruments, samples), BUT postpone the loading of the SDTA chunk. In fact, the biggest soundfont I have around is the "Musyng Kite original, old version". It's file size is 1 747 075 246 Bytes (==1.6 GiB). It's SDTA chunk alone is 1 746 365 570 Bytes in size. The rest, i.e. 1747075246 - 1746365570 = 709676 Bytes, is structural information. Do you really want to start optimizing the loading and parsing of those 700 KiB? With solely lazy-loading the SDTA chunk we would get rid of drawback no. 1. And if parsing all those structural information is yet too slow, we can still think about how to make it faster. Speaking of lazy loading the SDTA chunk: Wouldnt a memory mapped file perfectly fit this use-case? Instead of letting the sample data point to RAM, just make them point to the mem mapped file? Not sure what an impact mem mapped sample data would have on real-time rendered audio though... I do believe that this lazy-loading feature in general could also be useful for MIDI file playback, specifically for hiding latency prior playback start. Leading to drawback 2: Who is that mysterious separate thread? A thread that will be spawned on every fluid_synth_program_change()? In case of MIDI file playback it could just be the rendering thread? Not sure. Tom _______________________________________________ fluid-dev mailing list fluid-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/fluid-dev _______________________________________________ fluid-dev mailing list fluid-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/fluid-dev