[PD-dev] building fluid~ on Linux (was: [PD] fluid~ for Pd-Vanilla - test version)

Alexandre Torres Porres porres at gmail.com
Sat Jan 9 18:39:30 CET 2021

Ok, for reference, this
<http://midi.teragonaudio.com/tech/midispec/pgm.htm> 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
- https://github.com/pure-data/pure-data/blob/master/src/x_midi.c#L710

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

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?

Em sáb., 9 de jan. de 2021 às 13:14, Alexandre Torres Porres <
porres at gmail.com> escreveu:

> Em sáb., 9 de jan. de 2021 às 12:33, Alexandre Torres Porres <
> porres at gmail.com> escreveu:
>> +-----+-----+----------------------+----------------------+
>> |Bank | PC  | Name*                 |      Info.           |
>> +-----+-----+----------------------+----------------------+
>> | 000 | 000 | 1 [ Theater Upper ]  | No Sound, Title Only |
> 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
> https://sourceforge.net/p/pure-data/svn/HEAD/tree/trunk/externals/footils/fluid/fluid/main.cpp#l193
> 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
> https://git.purrdata.net/jwilkes/purr-data/-/blob/master/externals/fluid~/fluid~.c#L93
> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-dev/attachments/20210109/6fbc0ff7/attachment.html>

More information about the Pd-dev mailing list