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