> 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
https://github.com/tim-janik/beast/pull/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 or view it on GitHub:
https://github.com/tim-janik/beast/pull/85#issuecomment-485841233
_______________________________________________
beast mailing list
[email protected]
https://mail.gnome.org/mailman/listinfo/beast
