patches from Musescore to consider for adaption

[fabiangreffrath]

Hi there,

fellow Debian mate Thorsten Glaser suggested [1] to adapt the following patch from the Musescore project to Fluidsynth:

musescore/MuseScore#7728

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=985129#41

[mawe42]

Quite a large patch, difficult to see which bits are actually relevant for us. Especially since Musescore is based on an old version of FluidSynth, converted to C++ and therefore lacks many(!) of the fixes we've made to the codebase since then.

[mawe42]

@fabiangreffrath Do I understand this correctly that the musecore-general soundfont from Debian currently causes MuseScore to crash? If so, then we could definitely test that file against our current code.

[mawe42]

I've tested the latest MuseScore_General_Full.sf3 from the Debian repos (updated on 12th of March 2021) against the current stable version of FluidSynth, selected the Oboe (68) on a channel and can play notes just fine, no crashes.

The other changes in that patch seem to be very MuseScore specific (as is expected). So I must admit I don't know what else we should do here.

[mirabilos]

It caused a crash once, it’s unfortunately not reproducible. But I fixed a number of corner cases in sample loading (and yes, I shudder at the CFrustFrust as well) and the handling of {,loop}{start,end} for SF3 soundfonts, which is probably the important thing here. See https://musescore.org/en/node/89216 for more story on this.

I recall asking upstream MuseScore about when/whether they’d upgrade the MuseScore fluid synthesiser from recent FluidSynth, especially as the latter also gained SF3 format support in the meantime, and not geting a decisive answer. It’s probably too much effort for too little (commercially visible, or so) gain…

[mawe42]

The code doing the loop sanity checking in MuseScore is also very old. We had quite a few bug reports and weird corner cases that were due to problems with sample loop points. So my guess would be that the problems in MuseScore are not present in FluidSynth (anymore). But I'll try to read the MuseScore PR again to make sure.

I think both FluidSynth and MuseScore would benefit a lot if MuseScore would link against FluidSynth (again?). But then I don't really know what made them copy/fork the code in the first place. Oh well...

[mirabilos]

oic

fluidsynth/src/sfloader/fluid_sfont.c

Line 773 in b8fb6c8

int fluid_sample_sanitize_loop(fluid_sample_t *sample, unsigned int buffer_size)

has… quite some things. Do you really see soundfonts with loopstart/loopend reversed but valid? With loopend beyond end? (That won’t work with sf3 of course, and it wouldn’t work with the way MuseScore decided to load soundfonts…)

I’ve got no idea why they don’t just use libfluidsynth… that was years before I learnt of either, and I’m “just” the Debian packager, and upstream’s current new focus is on making things easier to use for newcomers which vastly outnumber existing users, especially users on FOSS operating systems :/ it’s still a good program though, and still fully open too.

[mawe42]

We've seen a lot of really broken soundfonts, especially older Soundfonts from "back then" are sometimes quite awful. Definitely ones with loopend beyond end. Can't say for certain if we've also found some where loopstart/end was reversed, but I think so.

This whole loop point and sample index checking has received a lot of work and quite some significant changes over the years. We decided to remove the checks for the minimum "padding" of loopstart/end relative to sample start/end (which your PR wants to add to MuseScore). Older FluidSynth code actually tried to fix those loop pointers, which resulted in artifacts. And FluidSynth doesn't need this padding anyway. Simply leaving those loop pointers as is works without problems.

[mawe42]

it’s still a good program though, and still fully open too.

I'm a MuseScore user myself and wholeheartedly agree: it's a fantastic program! Just a shame the synth is so buggy ;-)

[mirabilos]

Marcus Weseloh dixit:

We've seen a lot of really broken soundfonts, especially older Soundfonts from "back then" are sometimes quite awful. Definitely ones

Ouch, okay.

This whole loop point and sample index checking has received a lot of work and quite some significant changes over the years. We decided to remove the checks for the minimum "padding" of loopstart/end relative to sample start/end (which your PR wants to add to MuseScore). Older

Only as warning. It did trigger on a few samples in the default soundfont, which I reported to its author, so that he can fix them for portability…

resulted in artifacts. And FluidSynth doesn't need this padding anyway. Simply leaving those loop pointers as is works without problems.

… good to know but other software or hardware would still benefit from fixing them ;-) plus it can be an indicator of things going wrong. Thanks for the feedback, much appreciated!

[mawe42]

Thanks for the feedback, much appreciated!

You're welcome. Thanks for making FS in MuseScore better :)

[mirabilos]

Small update: apparently the working draft for MuseScore 4 contains a patched (“to remove glib dependency”, which I can applaud knowing glib…) copy of fluidsynth-2.1.4

This won’t fly in distribution packaging obviously, but I guess as long as they don’t patch anything else I can just use the system copy which does use libglib.