Hi Hamish,
Am Mo., 26. Okt. 2020 um 23:51 Uhr schrieb Hamish Moffatt
:
> While we're on the topic of soundfont loading, is there any possibility
> of speeding it up by using multiple cores?
That would require a fairly large code restructuring, the whole loader
was written with sequential single-t
While we're on the topic of soundfont loading, is there any possibility
of speeding it up by using multiple cores?
I'm loading two soundfonts in SF3 (vorbis) format, and they take a few
seconds each to load. This is now the majority of my app's startup time.
Two things would help; either allo
Hi,
there is a first RFC pull-request here:
https://github.com/FluidSynth/fluidsynth/pull/698
It implements the fluid_synth_pin_preset and fluid_synt_unpin_presets
by hooking into the preset notify callbacks that are already used by
the dynamic-sample-loading to load and unload the preset. Advant
> there is no thread-safe way of retrieving and using those pointers for
external applications (outside of the synthesis thread)
Valid point, indeed.
> What do you think about:
> fluid_synth_pin_preset(synth, sfont_id, bank, program)
Ok for me. Looking forward to it :)
Tom
___
Hi,
Am So., 25. Okt. 2020 um 11:34 Uhr schrieb Tom M. via fluid-dev
:
> 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*)
Yes, sounds good. And quite similar to the approach I used in the
earli
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 threa
