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