Ok, for reference,
this says that although program change numbers are from 0-127, there's no standard and some devices can index from 1, and I see Pd does index from 1, see:
-
https://github.com/pure-data/pure-data/blob/master/src/x_midi.c#L307
I think this should be mentioned in the Pd's help file...
Purr Data's smmf mode wants to be more plugin and play with pd's objects and made it 1-indexed for a new "pgm" message, but also altered the old legacy message, maybe unintentionally. I opened an issue over there.
As for what to do, I don't know. This is a quite old external that has been long lost to oblivion and I don't know how well we need to preserve its original design so it can run patches that used it some 15 years ago. I also don't know how crucial it is to port externals that are compatible to Purr Data compatibility between Vanilla and Purr is compromised to some extent in different levels so that can never be 100% achieved anyway (there are other objects that can only be found in Purr, and some objects like [trigger] have different functionalities and other things). To make it all more complicated, there's a new external from ceammc that has the exact same name (fluid~ ) and a completely different design and different functionalities.
What feels sane for me is creating a new object, with a different name (fluidsynth~) and its own design that is cleaner and doesn't try to fix this compatibility issues, cause it's just a nightmare with no simple solution. I like the idea of making it more compatible to Pd Vanilla and take messages in a more straightforward way from its internals, and I could do that by having that as a default and just removing the "legacy" stuff. That would make it all much cleaner...
Anyway, that's how I'm leaning now... what do you people think?