<div dir="ltr"><div dir="ltr">Em dom., 1 de mai. de 2022 às 16:40, Roman Haefeli <<a href="mailto:reduzent@gmail.com">reduzent@gmail.com</a>> escreveu:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Yeah, that's a good point. Having to grab it from ELSE is not a good<br>
advice, though, since as part of ELSE I can't do [declare -lib<br>
fluidsynth]. I'd have to [declare -path else] for non-obvious reasons.<br>
I don't think that nesting libraries is good practice and it might<br>
confuse  people searching stuff through Deken.</blockquote><div><br></div><div>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. </div><div><br></div><div>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.<br></div><div><br></div><div>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?</div><div><br></div><div>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... </div><div><br></div><div>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.''</div><div><br></div><div>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.</div><div><br></div><div> cheers</div></div></div>