[PD] fluild~ shared soundfonts update

[Larry Troxler]

Frank, I haven't heard from Norbert Schnell yet about his ideas about Max/PD 
compatibility; Is Norbert.Schnell at ircam.fr his current e-mail address?

The whole issue of how this should work is still murky in my mind. I realized 
another problem with the [ fluid~ drums.sf2 DRUMS] creation syntax; not only 
is there a problem with creating a fluid in the DRUMS group loading a 
different font, but to be consistent with a creation soundfont being 
equivalent to a load, then if you were to duplicate this object, then each 
you would end up with n instances of a a shared soundfont loaded n times into 
each fluid~ (since there is no check against loading a sounfont twice).

I'm almost tempted to consider a completely different approach: let's forget 
about the "group" idea and to just have the fluid~ load message (or 
creation-time soundfont) share a soundfont if the filename strings are equal. 
Of course, on most OS's, the same file can be reached by more than one 
pathname string, but I don't think it's a problem to require them to be 
referred to the same way if you want to share the soundfont.

This would require that a "reload" message be implemented, in case the 
soundfont file has indeed changed and you _do_ want to load it again. I seem 
to remember either a fluidsynth API for this, and/or that Norbert Schnell has 
already implemented reload in his Max version.

Another disadvantage of this new approach, would be that to share a soundfont 
among, say 32 fluids~ (not unreasonable if you want to treat each voice of a 
piano instrument seperately), you would actually have to patch the load 
command to all 32 of them if you don't specify it at creation time. However, 
I think perhaps that this is not too much of a problem, because for other 
reasons, you would probably have each fluid~ in this case be part of an 
abstraction, especially since in many cases they share the same audio 
post-processing.

Man oh man, this is sure taking more thought than I anticipated. This is one 
of those cases where a feature is trivial to implement for my own use, but 
more involved than it should be to get working in a way that makes sense for 
everyone. It's especially a shame because I doubt the shared soundfont 
feature would be important to  most of the people who use fluid~. Plus, it's 
kind of a kludge anyway; really it would be best if we could get the 
fluidsynth API to give seperate audio outputs for each voice (and then also 
specify which output a given note event goes to).

Best Regards 

Larry Troxler