Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
One fluid synth per track #102
This gets rid of all bse module locks in the fluid synth code, by using one fluid synth instance per track.
I observed that if we load the soundfont every time the user presses play, this can be slow (50ms to load fluid r2 * number of soundfont tracks), so this keeps the fluid synth instances even after the project stops playing, and re-uses the instances on play.
What this doesn't implement is changing the soundfont on a track while the project is playing (the gui doesn't let me do this anyway), but this could be implemented by preparing a new fluid_synth instance and exchanging it on the fly using an engine job.
I believe that this is the best/correct way to do it, better than #85
Instead, cache & reuse fluid synth instance if possible Signed-off-by: Stefan Westerfeld <firstname.lastname@example.org>
We no longer use the sound font repo fluid synth instance for synthesis, this simplifies the code. Signed-off-by: Stefan Westerfeld <email@example.com>
tim-janik left a comment
The reason the GUI blocks instrument changes is that the BSE core hasn't had support for this yet. If soundfonts can implement changes during runtime, the associated, we'll of course release that restriction and make it user accessible. I guess that's better left for another PR, right?
I agree. As I understand it, updating beast-gtk is to be avoided, I suppose this should be done once ebeast supports assigning soundfont & preset with the new ui. The fluid code as it is supports changing the preset of an existing track during play. It doesn't support changing the SF2 filename of a track during play, but this could be implemented by swapping the fluid_synth_t instance in this case. Maybe that should be done after you have the new engine module api.
Anyway I think I've addressed the other issues now, will reassign this to you so you can merge it.