Em dom., 1 de mai. de 2022 às 16:40, Roman Haefeli reduzent@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