Support per-note detuning and panning with Sf2 Player

[DomClark]

See title. Panning only works with FluidSynth >= 2.0, unfortunately, since that's when the GEN_CUSTOM_BALANCE generator was introduced. There is a GEN_PAN generator that works with older versions, but the channel attenuation doesn't match that of LMMS's other native instruments.

I have introduced an ArrayVector class in this PR that is effectively a std::vector equivalent that stores its elements like std::array does. There are numerous third-party implementations out there, but I couldn't find one that was both maintained and didn't come as part of a massive library of things we don't need. (There's even a C++ standards proposal for one, but I don't believe it has been incorporated yet, so we probably won't see it until C++26 at the earliest.) I've wanted a container like this for a couple of purposes, and as the rest of this PR was quite small, I thought it would be a good place to introduce it. It allows vector-like operation without heap allocations, so is useful in real-time code.

[Monospace-V]

I am wondering if older files with (non-working) detuning on sf2 player will play as intended? I believe previous behaviour was to play the note it happened to be at the start, and any 50 cents detuning rounded off.

(This would play an F, then a G#.)

I have checked and found files where my SF2 player has pitch bend on the piano roll, possibly because I copied them over from a different instrument.

Is it possible to retain compatibility, or will all existing old files need to be manually modified for sounding like they did before?

[YohananDiamond]

I'm not sure on how LMMS handles old version files, but maybe there could be a pop up that asks if you want one thing or the other (converting it to an accurate version of the pattern accordingly)

[messmerd]

I think we should either bump the required FluidSynth version to 2.0 or later, or provide a warning in the CMake output when per-note panning is not supported.

The CMake output currently looks like:

* SoundFont2 player           : OK

But if we do not bump the FluidSynth version, it should read something like:

* SoundFont2 player           : OK (per-note panning enabled)

[...or...]

* SoundFont2 player           : OK (FluidSynth version < 2.0: Per-note panning disabled)

[DomClark]

I think we should either bump the required FluidSynth version to 2.0 or later, or provide a warning in the CMake output when per-note panning is not supported.

This sounds like a good idea. Linux, Mac, and MSVC builds use the FluidSynth version from their respective package managers, which is already at least 2.0 for Mac and MSVC. Linux builds are still on Ubuntu 18.04, which has 1.1.9, but when we upgrade to 20.04 (which we can now do), we'll get 2.1.1. MinGW builds are trickier, as these use a custom PPA which tobydox builds for us, and currently have version 1.1.8. I don't know whether we'll be able to switch to MSVC builds for Windows releases before we get to the RC stage for 1.3, or whether we should contact tobydox for an updated FluidSynth version.

I am wondering if older files with (non-working) detuning on sf2 player will play as intended? [...] Is it possible to retain compatibility, or will all existing old files need to be manually modified for sounding like they did before?

It will certainly sound different from before. Which one is intended is a different question, and the answer may depend on the particular user and project. I'm inclined to avoid removing anything from the project automatically if the user might want it - it's a lot easier for them to remove it themselves than add it back. Plus, this depends on FluidSynth version, not just LMMS version, so sharing projects between identical LMMS versions could still sound inconsistent.

Maybe there could be a pop up that asks if you want one thing or the other

I would rather not add user interaction to the project loading code - it would complicate command-line rendering for one thing, as well as adding some GUI dependency into the core, which is undesirable for technical reasons.

If removing unwanted automation does turn out to be tedious, I would instead suggest a context menu item or button within the song editor or piano roll to remove all per-note automation from a clip. Feedback on this idea, or better ideas, are welcome.

[messmerd]

LGTM. No problems found while testing.