Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.Sign up
freewheeling 0.6.4 doesn't build with fluidsynth 2.0 #12
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
I don't think I'll switch anytime soon. Attempted rebuilds of all dependants, and aside from two, all break.
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.
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: