Re: [tim-janik/beast] BSE: SF2: use shared engine module instead of global soundfont lock (#85)

In that case, there should be one engine module around the fluid_synth_t instance, and the other modules should connect to this one module as input.

Yes, this PR does about half of what you ask; it uses one shared engine module around the fluid_synth_t instance (good), but on the other hand accesses the fluid_synth_t instance from all engine modules (bad), so it still needs a lock. It could be fixed in this PR, but I now believe it is better to use a different approach; on fluid_synth_t instance per osc, as submitted in #102

As stated above, ultimately the code needs to be reworked to avoid the lock and use jobs or similar means to update engine module state.

Can we get rid of the shared state once the fixed fluidsynth 2.0.5 is out, or is this unrelated?

This is unrelated. Using fluidsynth 2.0.5 mainly allows us to fix the deprecation warning.

You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]