search

tim-janik / beast

Beast - Music Synthesizer and Composer
GNU Lesser General Public License v2.1
83 stars 12 forks source link

One fluid synth per track #102

Closed swesterfeld closed 5 years ago

swesterfeld commented 5 years ago

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 https://github.com/tim-janik/beast/pull/85

swesterfeld commented 5 years ago

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

swesterfeld commented 5 years ago

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.