[PD-dev] building fluidsynth~ (was: building fluid~ on Linux)

[Alexandre Torres Porres]

Em dom., 1 de mai. de 2022 às 16:40, Roman Haefeli <reduzent at gmail.com>
escreveu:

> Yeah, that's a good point. Having to grab it from ELSE is not a good
> advice, though, since as part of ELSE I can't do [declare -lib
> fluidsynth]. I'd have to [declare -path else] for non-obvious reasons.
> I don't think that nesting libraries is good practice and it might
> confuse  people searching stuff through Deken.


This implies that fluidsynth~ as an external is presumably a nested
external library. As if it couldn't be ever considered as part of ELSE or
any other library. I know there's been a 'fluid~' external at some point
made available on its own, but fluidsynth~ is not fluid~, fluidsynth~ has a
distinct design, and there's no reason or rule that it has to be made
available on its own.

The last update of ELSE carries [score] objects that I think are really
useful to write scores. The fluidsynth~ addition will be great as a
counterpart so people can write scores to be played by fluidsynth~ as well
as other oscillators from ELSE.

I can see it could be nice/useful/desired to have it as a single external,
but so would be many other externals from ELSE. For instance, else has many
reverb objects and includes a reverb based on the gigverb
algorythm (giga.rev~) as well as anoter based on the freeverb algorithm
(free.rev~) - there are single externals in pd also based on both
algorythms but the objects in ELSE are not exactly the same and have a
different design. Imagine there weren't such objects made available as
single externals, why should I make them available as single externals
instead of as part of ELSE?

Anyway, deken is able to search for externals inside libraries, so people
using deken and searching for fluidsynth~ will find ELSE, and if you have
[declare -path else] in your patch you're telling people they should have
ELSE...

Now, when I say people could 'grab' from ELSE, i meant it in some cases
where they would want to ship projects with prearranged and preinstalled
dependencies/externals, so one could just include fluidsynth~ in some
'dependencies' folder and ship it.''

By the way, ceammc has a fluid~ object and it is part of the ceammce single
binary pack, so if one just wanted fluid~ they have to include the whole
ceammc pack with over 700 externals. I'm just saying I offer an advantage
over that with my single binaries for each external.

 cheers
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-dev/attachments/20220501/bf550829/attachment.htm>