@Il-pleut Yes, i agree. Fun thing is, by only using the [declare] method, you can always start Pd in vanilla mode (empty startup list) and load the externals on patch level.

Here are at least some hints from the mailing list:

Dan Wilcox (Feb 12 2020):

Deken initially did this, but there are problems with this approach as it partially negates the usage of [declare]. It is highly recommended to use [declare] moving forward.

https://lists.puredata.info/pipermail/pd-list/2020-02/126896.html

The idea with [declare] is similar to Python "import". We have moved away from Pd-extended's "just load everything into the same name space" approach towards a more explicit declaration for paths and libs. This requires an extra step but it also helps make patches more portable in that it is much clearer to see what libraries the original author specifies as opposed to "oh I guess it worked in Pd-extedend but I have no idea what externals those objects come from."

https://lists.puredata.info/pipermail/pd-list/2020-02/126906.html

Here is a proposal from 2018 to get [declare external]: https://github.com/pure-data/pure-data/pull/440

@whale-av Yes, as i understand it, using [declare] for all externals is the recommended way to include that list. Bonus is that it will also load the externals whether or not they are in the settings.

@Il-pleut Yes and also the behavior and recommended way of handling externals have changed over time. In the beginning, you had to do everything manually, then "Find externals" (also called Deken) copied the files but you had to add the path manually, then "Find externals" also automatically added the path.

Now in Pd 0.50.2 there is an option to add the path automatically, but it is recommended to use [declare] instead. The idea is that there is a clear reference inside the patch which externals are used. So if you download a patch from somebody else and some objects are missing, you can find out which externals are used by inspecting the patch.

@casper You ask for a zero if the input is below 50 and above 60 which is never true, so you only get a one.

What you probably want is [expr if($f1 > 50 && $f1 < 60, 1, 0)] or [expr if($f1 >= 50 && $f1 <= 60, 1, 0)].

You can also use "or" which is ||, so: [expr if($f1 < 50 || $f1 > 60, 0, 1)] or [expr if($f1 <= 50 || $f1 >= 60, 0, 1)].

[declare purest_json] should be sufficient and Pd should determine how to handle it internally, but it is not and it does not.

So for now, only [declare -path purest_json] works.

@yannseznec No, as far as i know, only some externals are actual libraries, one example is Gem. For the user this distinction is irrelevant and it is also hard to find out which is which. A complexity that should be hidden from the user and a minor flaw in Pd in my opinion. Most externals will require -path.

@yannseznec I can reproduce the issue. However, using [declare -path purest_json] works.

This should be the safest and cleanest way.

@yannseznec Sure, for yourself this is perfectly fine, but sharing patches with externals included doesn't seem a great way. I tried this in the past and it was a mess.

@Il-pleut From what i read the newly preferred way is to use [declare] if you use externals.

Copying the externals into the patch might be possible but could lead to conflicts, if the externals are updated in the future and the old ones are loaded with the patch? I am not sure about the order of loading externals in such a case, but i would discourage this solution.