<div dir="ltr"><div>Ok, for reference, <a href="http://midi.teragonaudio.com/tech/midispec/pgm.htm">this</a> 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:</div>- <a href="https://github.com/pure-data/pure-data/blob/master/src/x_midi.c#L307">https://github.com/pure-data/pure-data/blob/master/src/x_midi.c#L307</a><br><div>- <a href="https://github.com/pure-data/pure-data/blob/master/src/x_midi.c#L710">https://github.com/pure-data/pure-data/blob/master/src/x_midi.c#L710</a><br></div><div><br></div><div>I think this should be mentioned in the Pd's help file...</div><div><br></div><div>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.<br><br>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.</div><div><br></div><div>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...</div><div><br></div><div>Anyway, that's how I'm leaning now... what do you people think?</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Em sáb., 9 de jan. de 2021 às 13:14, Alexandre Torres Porres <<a href="mailto:porres@gmail.com">porres@gmail.com</a>> escreveu:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"></div><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Em sáb., 9 de jan. de 2021 às 12:33, Alexandre Torres Porres <<a href="mailto:porres@gmail.com" target="_blank">porres@gmail.com</a>> escreveu:</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote">+-----+-----+----------------------+----------------------+<br>|Bank | PC | Name* | Info. |<br>+-----+-----+----------------------+----------------------+<br><div>| 000 | 000 | 1 [ Theater Upper ] | No Sound, Title Only |</div></div></div></blockquote><div><br></div>What I see now is that program numbers should be indexed from 0, right? As it is, program 1 refers to program 0 on the program list, so it is indexed from 1 instead! That is, the code is subtracting "1", but I checked the original fluid~ code and it doesn't do that, see <a href="https://sourceforge.net/p/pure-data/svn/HEAD/tree/trunk/externals/footils/fluid/fluid/main.cpp#l193" target="_blank">https://sourceforge.net/p/pure-data/svn/HEAD/tree/trunk/externals/footils/fluid/fluid/main.cpp#l193</a></div><div class="gmail_quote"><br></div><div class="gmail_quote">On the other hand, I was using the port to Pd's API from Purr Data and that subtraction was introduced in the code then, see <a href="https://git.purrdata.net/jwilkes/purr-data/-/blob/master/externals/fluid~/fluid~.c#L93" target="_blank">https://git.purrdata.net/jwilkes/purr-data/-/blob/master/externals/fluid~/fluid~.c#L93</a><div><br></div><div>I considered that a backwards compatibility breakage and also a bug and I don't know what to do now. Purr Data's version also introduced "smmf" mode and I was keeping it all just so an external or a patch from Purr Data that uses fluid~ could run in Pd Vanilla, but I don't feel like keeping this bug/breakage. So I can ask them to fix it over there or just fix the bug and remove "smmf" mode and compatibility to Purr Data.</div><div> </div></div></div>
</blockquote></div>