freewheeling 0.6.4 doesn't build with fluidsynth 2.0

[dvzrv]

I currently did a bunch of rebuilds against fluidsynth 2.0.0, which introduces API changes.

This unfortunately breaks building freewheeling 0.6.4:
freewheeling0.6.4-fluidsynth2.0.txt

It would be awesome to make freewheeling compatible to fluidsynth 2.0.0!

[bill-auger]

were you planning to carry both fluidsynth and fluidsynth2 for some transitional period? - i ask because the debian multimedia team told me they probably will not add fluidsynth2 before the freeze because nothing in debian actually uses it yet - do you know of any programs in arch that uses it today?

let me know what your plans are - i will look into it; but maybe this not such a pressing issue? - depending on the changes this entails, it could literally mean freewheelling would need to support both versions of fluidsynth - for any program that does not yet use any of its new features of this new fluidsynth release, the: "... but 2 is more than 1" argument really doesnt justify jumping so quickly to it - i suspect you will find that to be the general consensus

for freewheeling, it would make more sense to remove fluidsynth support entirely rather than support both versions of it - this program doesnt really need a synth anyways; and it is already optional per a configure switch

[dvzrv]

I don't think I'll switch anytime soon. Attempted rebuilds of all dependants, and aside from two, all break.
https://git.archlinux.org/svntogit/community.git/tree/trunk/PKGBUILD?h=packages/fluidsynth#n6

I think qsynth is already able to support it on git HEAD, but all other projects are either just now starting to work on it (or trying to (re-)move it).

It currently doesn't make sense for me to upgrade, as I'd have to provide two versions of fluidsynth and maintain a hackjob.

However, if more and more projects pick it up in the near future, I'll consider it. From a work-load point of view, I'd rather do an all-or-nothing switch though.

[dvzrv]

We're down to only csound not supporting the new API and for that build I will just not use it anymore. Time to implement!

In case you need some insight into how other projects dealt with it:
LMMS/lmms#4640
falkTX/Carla#758
calf-studio-gear/calf#202
https://sourceforge.net/p/qsynth/code/ci/27ac18f496bd9001ee80d519cae757ecff2855f6/log/?path=v

[bill-auger]

done 18e9844