One fluid synth per track

[swesterfeld]

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

[swesterfeld]

As requested, I've updated this branch so that it doesn't require fluidsynth >= 2.0.5.

[tim-janik]

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.

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?

[tim-janik]

We need to get rid of global using clauses. The std namespace defines lots of lower case symbols/types that are likely to clash with variable names in our code, so it's best to always use explicit prefixing (like std::string, std::max). For this case specifically, there's also Bse::String, so at least inside the Bse namespacse, String can simply be used. Also, using clauses are not as bad in inner scopes, like do { using Bse; String s; ... } while (...)

[swesterfeld]

Right, I've fixed this now by using std::string - I also tried using Bse::String - this doesn't have any advantage here, as all code is outside the Bse namespace.

[tim-janik]

Should be std::string.

[tim-janik]

It'd be better to merge the above two lines into delete_fluid_settings (&fluid_settings); where delete_fluid_settings automatically assigns NULL to the pointer passed in.

[swesterfeld]

delete_fluid_settings is part of the fluid synth api, so I cannot change what it does

[swesterfeld]

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.