Page 1 of 2
64-bit Fluidsynth?
Posted: Wed Mar 04, 2015 4:06 pm
by Major Cooke
The only version hosted on the
wiki is the 32-bit version. Would it be possible to supply a 64-bit version?
Re: 64-bit Fluidsynth?
Posted: Sun Mar 08, 2015 5:55 pm
by randi
Don't know if I want to go through all the pain of recompiling all its dependencies for 64-bit Windows when I don't remember specifically what they were.
Re: 64-bit Fluidsynth?
Posted: Sun Mar 08, 2015 7:48 pm
by NeuralStunner
Personally I'd recommend switching to the BASSMIDI driver. It's got great sound and I think performs better than Fluidsynth. You also then wouldn't have to worry about an extra library for 64-bit ZDoom builds.
Re: 64-bit Fluidsynth?
Posted: Sun Mar 08, 2015 11:35 pm
by BlueInferno
Bassmidi plays just about every soundfont flawlessly vs fluidsynth screwing up some soundfonts I used. CT8MGM.SF2 along with others dont run at all on it.
Re: 64-bit Fluidsynth?
Posted: Mon Mar 09, 2015 1:57 am
by Graf Zahl
NeuralStunner wrote:Personally I'd recommend switching to the BASSMIDI driver. It's got great sound and I think performs better than Fluidsynth. You also then wouldn't have to worry about an extra library for 64-bit ZDoom builds.
But then you'd have to worry about a SYSTEM DRIVER!
Re: 64-bit Fluidsynth?
Posted: Mon Mar 09, 2015 4:48 am
by Edward-san
BASSMIDI
No linux or mac? Your argument is invalid.
Re: 64-bit Fluidsynth?
Posted: Mon Mar 09, 2015 10:11 am
by NeuralStunner
Graf Zahl wrote:But then you'd have to worry about a SYSTEM DRIVER!
One that's stable and works in any other MIDI-capable program, yes. I don't see the problem.
Re: 64-bit Fluidsynth?
Posted: Mon Mar 09, 2015 10:55 am
by Graf Zahl
Of course you wouldn't. I prefer solutions that don't include system features that may become broken in the future. The MIDI stuff already fell victim to this once.
Re: 64-bit Fluidsynth?
Posted: Mon Mar 09, 2015 11:00 am
by NeuralStunner
How's it any different from using any other system synth? But that's fine. I was just giving Major Cooke a tip to begin with.
Edward-san wrote:No linux or mac? Your argument is invalid.
I don't think he uses either of those. Regardless, a win32 fluidsynth.dll is going to be just as worthless on those systems.
Re: 64-bit Fluidsynth?
Posted: Mon Mar 09, 2015 11:42 am
by _mental_
NeuralStunner wrote:Edward-san wrote:No linux or mac? Your argument is invalid.
I don't think he uses either of those. Regardless, a win32 fluidsynth.dll is going to be just as worthless on those systems.
It's quite easy to build Fluidsynth on Linux, and with some minor difficulties on Mac. Only Windows version requires very complicated setup to do so.
Re: 64-bit Fluidsynth?
Posted: Mon Mar 09, 2015 12:29 pm
by Major Cooke
Wondering if there's a universal one where any of the three versions can just produce a re-usable dll by windows, mac or linux. If so, perhaps, in that case mental, you could provide?
Re: 64-bit Fluidsynth?
Posted: Mon Mar 09, 2015 4:28 pm
by randi
No, Windows uses PE, Mac uses Mach-O, and Linux uses ELF. They're not compatible with each other. And even if they were, the dependencies of the dll/dynlib/so would be different on the different systems.
Re: 64-bit Fluidsynth?
Posted: Sun Mar 22, 2015 9:18 pm
by VGA
I use Coolsoft Virtualsynth
Although there is a little lag when a song is starting because it's preloading the 64mb soundfont I use I think.
Re: 64-bit Fluidsynth?
Posted: Wed Apr 01, 2015 10:19 pm
by randi
Guess what! I built a 64-bit Fluidsynth DLL. Unfortunately, all it produced for sound was a loud high-pitched buzzing that drowned out all other sounds. (Maybe the scaling is way off?) No idea what I did wrong. Maybe I'll try again later.
Oh, and for posterity: The dependencies I needed were
win-iconv,
libintl, and
glib.
Re: 64-bit Fluidsynth?
Posted: Thu Apr 02, 2015 9:01 pm
by randi
Here:
FluidSynth in 64-bit glory
Compiled with the default VS2013 toolchain, so it only works on Vista and up. Turns out I should have paid attention to the warnings instead of assuming they were benign (since the majority were about ptrdiff_t -> int truncation). It wasn't using config.h, so <math.h> was not getting included, which meant all the fp math routines were using the default prototypes that returned ints. Disaster ensued.
Building in 64-bit also revealed a minor problem I had with the original 32-bit build, so I redid that. Anybody using it might want to redownload it.
An interesting project to try sometime might be to "fix" it so it can use native Windows API calls instead of glib so that it can be built more easily for Windows systems.