Various fluid~ initialization fixes

Fixed some errors in the fluidsynth settings, and made fluid~ a lot less chatty by setting up fluidsynth log callbacks. Even that doesn't prevent a lot of log messages from drivers (especially from ALSA on Linux), though, so as a last resort the final commit also temporarily redirects stderr to /dev/null to get rid of all that noise.

requested review from @jwilkes

assigned to @jwilkes

mentioned in commit 733cf0ba

One question-- is there a way to redirect that initialization spam to the Pd console instead of /dev/null? Given that this external's dependencies break so often, I'd hate for a user to lack any errors that are helpful to us.

As long as it's posted to the Pd console I can use [unpost] to turn it off.

Digression-- is there a way to have Purr Data default to grabbing all the stderr and send it to the Pd console? Would bad things happen if that were a default?

You mean as a debugging aid for fluid~? That may occasionally be useful, but it won't help sort out these dll dependency problems. Because if the dependencies are broken, then the external will just refuse to load and there won't be any output whatsoever from it, end of story.

But in general I see why you may want an option to debug potential fluid~ startup issues. Any errors from fluidsynth itself are already captured and posted to the console by means of the fluidsynth logging callbacks in rev. 430ca9ea; I could still add the warnings back in there, too. I could also add a -v option for the debugging log from fluidsynth, and the other output not related to fluidsynth. But this really needs to be opt-in. You don't want to shock the average unwashed user by mercilessly spamming the console with all that ALSA or PortAudio device discovery ghibberish and the like -- it will scare them. ;-)

Right now I'm not even sure that rev. 38f49bce compiles and does the right thing on Windows -- that's why I was so eager to see the build log of the Windows runner in the first place. ;-) (No worries, I can fire up my Windows system and build it there myself.)

But if the answer is yes, then I could just create a temporary file, redirect stderr to that, then read back the file once initialization is finished and post its contents to the console.

Digression-- is there a way to have Purr Data default to grabbing all the stderr and send it to the Pd console? Would bad things happen if that were a default?

In principle it should be possible, yes, in the same way I sketched out above, if I can get it to work on Windows that is. But that would bring with it the same caveats as I pointed out above, only on a much grander scale, so making this the default wouldn't be advisable IMHO.

Let me give fluid~ -v a whirl first, then we can see how we like it, and whether we could adopt a similar solution globally.

Wow, looks like Windows even has pipe() (or rather _pipe()), that should make porting things much easier.

added 5 commits

• 9db86c6c - fluid~: Enable fluidsynth warnings in logging to the Pd console.
• d61df142 - fluid~: Capture stderr to the console if requested (new -v option).
• c0ca6fda - fluid~: Enable the user to set the synth.gain value (new -g option).
• cf2fc7cc - fluid~: New gain message which lets the user set the synth.gain value at runtime.
• 7a7ed83b - fluid~: Update help message.

Compare with previous version

There you go:

As can be seen in the screenie, -v now captures stderr to the Pd console during startup. I also re-enabled fluidsynth logging of warnings.

While I was at it, I also sneaked in a -g option and a corresponding gain message which allows you to set the fluidsynth synth.gain parameter at initialization and at runtime, respectively. This solves one of my pet peeves with fluid~ (wrong default volume, which also depends on the soundfont that you're using).

I still have to test this on Windows and Mac.

added 3 commits

• 28dc59aa - fluid~: Windows/msys2 fixes.
• c96859c9 - fluid~: Add missing Windows dlls.
• 35c9bcab - Pull mingw64 build changes over to mingw32.

Compare with previous version

Ok, with the last three commits it now also builds (and runs properly) on Windows. I added the missing dlls (libgomp et al) and, while I was at it, also pulled over the necessary changes to the mingw32 build.

But the latest msys2 dlfcn package is broken (again), so Gem doesn't work. (I checked this also with your build, and it exhibits the same issue.) You can find all the gory details in !719 (merged), but the TLDR is that dlfcn needs to be downgraded to version 1.2.0 to make Gem work. I'm attaching the required mingw64 package below (install with pacman -U mingw-w64-x86_64-dlfcn-1.2.0-1-any.pkg.tar.xz).

mingw-w64-x86_64-dlfcn-1.2.0-1-any.pkg.tar.xz

On the bright side, the OSX build went painlessly, worked on first attempt. :) I can upload my Mac and Windows builds here, if you want to give them a whirl.

BTW, it's interesting to note that fluid~ only seems to be that verbose on Linux/ALSA, there are no driver messages at all from stderr on Mac or Windows.

And, for the record, here are the fluid~ examples that I used for testing (have a look at fluid-test.pd and fluid-v-test.pd): fluid-tests.zip

mentioned in merge request !835 (merged)

merged