You also need to add libgomp-1.dll and libssp-0.dll, otherwise fluid~ won't load. Yeah, it's libfluidsynth and its ever-growing dependencies on msys2 all over again, we went through all this multiple times before (last time was with libfluidsynth-2, see #690 (closed)). ;-)

And yes, I did test with your latest Windows build, congrats for getting the Windows runner back up and running!

Is there a simple test we can create for fluidsynth to catch this stuff?

Yeah, something like ldd or otool would be nice to have, but I don't think anything like this exists for Windows. Maybe dlltool can do this kind of stuff, but I haven't used it in a long while. They way I'm figuring this out now is with an ancient GUI program named depend22 which lets me view the dependency tree of a dll, and flags any dlls it can't find. Usually it also produces many false positives, but I know what to look for. ;-)

No, I mean a simple creation test for [fluid~] in scripts/regression_tests.pd.

That will be trivial to add. Unfortunately, right now the underlying fluidsynth lib won't shut up about it's warnings and errors on instantiation:

fluidsynth: warning: SDL2 not initialized, SDL2 audio driver won't be usable
fluidsynth: error: Unknown numeric setting 'synth.midi-channels'
fluidsynth: error: Unknown numeric setting 'synth.polyphony'
fluidsynth: error: Unknown string setting 'synth.chorus.active'
fluidsynth: error: Unknown string setting 'synth.reverb.active'
fluidsynth: error: Unknown string setting 'synth.ladspa.active'

Any idea what all that garbage is? It gets printed to the terminal but not the Pd console, so I have no control over it.

My [fluid~] instantiates properly in both a test patch and the help patch. Any idea what's going wrong? I can't add the trivial test if it's going to consistently spam the CI log with stuff I don't understand.

fluidsynth: warning: SDL2 not initialized, SDL2 audio driver won't be usable

Well, I don't think that we can do anything about this. msys2 has a fluidsynth which is linked against SDL2, but we don't use SDL2, so of course SDL2 won't be initialized.

fluidsynth: error: Unknown numeric setting 'synth.midi-channels'
fluidsynth: error: Unknown numeric setting 'synth.polyphony'
fluidsynth: error: Unknown string setting 'synth.chorus.active'
fluidsynth: error: Unknown string setting 'synth.reverb.active'
fluidsynth: error: Unknown string setting 'synth.ladspa.active'

That seems to be wrong or outdated code in fluid_init. Don't kill me, I didn't write it. ;-) But I think that I can fix it, stay tuned.

The funny thing is, here on Arch, libfluidsynth is linked against SDL2, too, but it doesn't print that warning.

There you go: !834 (merged). I had to to some lengths, since on Linux at least the driver initialization is awfully chatty. I also set up some log handlers so that the important messages from fluidsynth get redirected to the Pd console.