Hm, looking at the code and thinking about this some more... You suggested something like fluid_synth_pin_preset(synth, fluid_preset_t*)
The problem here is the fluid_preset_t pointer. Exposing a public API that consumes fluid_preset_t pointers will introduce some problems, as there is no thread-safe way of retrieving and using those pointers for external applications (outside of the synthesis thread) and without implementing a separate Soundfont loader. What do you think about: fluid_synth_pin_preset(synth, sfont_id, bank, program) fluid_synth_unpin_preset(synth, sfont_id, bank, program) Cheers Marcus Am So., 25. Okt. 2020 um 11:34 Uhr schrieb Tom M. via fluid-dev <fluid-dev@nongnu.org>: > > Ok, I see. > > So, my preference of implementing this is to use the pinning approach. > > I'm thinking of a function like > > fluid_synth_pin_preset(synth, fluid_preset_t*) > > The function will attempt to pin all samples of the given preset and > load them into memory, if they are currently unloaded. "to pin" in this > context means preventing them from being unloaded by an upcoming channel > prog change. If successful, FLUID_OK is returned. > > If the preset doesn't support pinning (because it's a DLS preset, which > doesn't use the sample cache currently), FLUID_FAILED is returned. > > If the preset supports pinning, but dynamic-sample-loading is disabled, > FLUID_OK is still returned. Not an error, it is already loaded and will > never be unloaded. > > No exposing of the internal sample cache is needed. > > Ofc, we'll need a way to unpin presets. I'd vote for a separate "unpin" > function. This function should unset the is_pinned flag. Again, if the > preset doesn't support pinning, FLUID_FAILED is returned. Ideally, the > function also unloads the samples if the given preset is no longer > referenced by any channel. In this case, care must be taken to avoid a > race condition with the rendering thread: If you unload the samples from > memory (because the ref count was zero) and just right afterwards, the > rendering thread selects the sample again, then just make sure that the > sample is first being unloaded cleanly and then loaded back cleanly. > Can't remember if you were already using some kind of synchronization > like that, didn't had a look. > > Thoughts? > > > 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
