Frank, I haven't heard from Norbert Schnell yet about his ideas about Max/PD compatibility; Is Norbert.Schnell@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