I'm working on a patch at the moment using purest_json, which works well once it is up and running.

A weird thing, though: the purest_json objects will not load when I open my own patch first. If I go into the externals folder and open a help file for one of the objects (rest-help.pd, for example), the objects will load perfectly. I can then close that patch and re-open mine, and the objects will work fine.

I have a [declare -lib purest_json] object in the patch already, for what it's worth.

I have to repeat this process each time I quit and relaunch PD. I don't have to do it for any other externals I have installed. Any ideas how I can avoid this?

From what I know :

Usual solution -> add the path of the library's folder in the startup path preferences.

Iron solide solution -> copy the external file into the patch folder. // this solution is not that good and can lead to problems, read below.

If you want to share your patch with those externals, you have to add a readme with the references of all the librarys involved.

thanks!

The library was installed using the library manager...I did this with my other external libraries and they work fine, so I'm pretty certain my path preferences are ok.

That's a good idea to copy the externals into the patch folder. Seems a bit strange to have to do that for these externals only, but whatever works is ok with me.

@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.

@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.

ah ha, yeah I can imagine it would create issues. I suppose if I only use these externals for this project then I could remove them from my standard externals folder to avoid conflicts. However it sure feels wrong (and doesn't really address the underlying question of why this is happening!)

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

This should be the safest and cleanest way.

oh wow yes that works @ingox many many thanks!

I don't know why -path works better than -lib, I wonder if it's a PD-wide issue, or just specific to this library?

Either way, it works, I won't complain

thanks a bunch. I'll be sharing this patch I'm working on really soon...

@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.

[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.

The fact seems to be, when you look for an external, library, abstraction, no matter how much directorys you have into your startup path list, PD will check what's inside those directorys, but not what's inside the directorys contained inside those directorys.

Plus, PD will check the folders containing your current patchs, but not what's inside the sub folders.

Maybe this could make too much ?

So you have to write the name (or path if it is necessary, because the library/external folder is inside a sub directory of one of those directory) of this particuliar folder that contained the file you want.

You also have to write a flag.

Depending on wich flag you use, it will checkt into the startup path directorys+ the patch's directory (path / lib flags) or into the PD's "extra" directory (stdpath / stdlib flags), if there is a folder of that name.

I needed to think through that.

@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.

@yannseznec As I understand it a library that requires a -lib flag has to be closely integrated with the Pd binary as it loads. Most libraries have no such needs, and can simply be pointed to after Pd loads by setting the path so that they are found.
If it requires the flag...... like Gem and zexy........ the user will have to have it installed and path setting in any form (settings or declare) will be insufficient.
If it does not require the -lib flag then you could copy the binary of the external and its help files into the folder containing your patch and share that (licences permitting)......... although that will not help anyone using a different operating system.
Maybe we should all be including a list of external libraries required in all the patches we share.
David.

@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.

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

Might sounds stupid, but a button to toggle on and off all the librarys ( a vanilla mod) could be useful sometimes.

@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.

My search path and startup path are emtpy, and pd still finds the iemguts/canvasdelete object. The library is installed in the library/pd/iemguts folder, and this is where the download manager put it.

Modification: You need to unselect "use standard path" and then relauch. Then the library inside the library folder are ignored.

@Il-pleut @ingox @yannseznec Depending on interest and whether I can be enthusiastic.....
Please put this in a known search path........ vanilla-plugin.tcl
Start Pd.... Clear the console.... open "media" "Vanilla Mode...." ........ and post what you get in the console and your OS (Mac/Linux)........... I only need one of each unless you get something wildly different (I am using Windows).
Ignore the pop-up window.
Close Pd.
Delete the file you uploaded (unless you want to keep it..... it will tell you all the paths searched by Pd.....).
I am just trying to ascertain the different search path settings on different OS's to see if this will be simple or hard and how to progress.
David.

Does this TCL file things work for all program ? I mean, could you add any fonctionnality to any program, just like that ?

One thing: the "vanilla mod" button appears on the preference menu, not on the media one.

Here is what you get on mac:

Enabled Path /Applications/Pd-0.50-0.app/Contents/Resources/extra
Enabled Path /Library/Pd
Enabled Path /Users/user_name/Library/Pd

@Il-pleut Pd depends on tcl. You could do it for other programs that use it I suppose.
You mentioned /Library/Pd above.
I see there are two of them.
What folders are in there?...... just externals or some basic Pd stuff as well?
David.