I installed Cyclone with Deken, added it to the path, and set it as a startup library. In a new patch, I can create Cyclone objects successfully. But when I right-click on an object and choose Help, I get "couldn't create" errors in the console.

As an example, I successfully created an avg~ object. When I open its Help, I see "couldn't create" errors for cyclone/avg~, cyclone/train~ 200, four cyclone/comments, cyclone/scope~, and cyclone/setdsp~.

Any idea why this happens?

Forgot to mention that this is on Windows 10.

It seems that the cyclone developers assume that you put the cyclone folder in Pd/externals without putting the cyclone folder in Pd's search path, and then load the objects with the cyclone prefix as it is with the objects of this library in their help patches. I actually agree with this approach as it is easy to figure out which library an external belongs to.
Try removing the cyclone folder from Pd's search path but make sure the cyclone folder is in a folder where Pd will look at, externals is a good place for this. The try to load an object like this [cyclone/avg~] and open its help file.

Thanks, Alexandros, your recommendation worked. I removed cyclone from the Pd search path and moved the cyclone folder into the Pd/extra folder. (There is no externals folder in my Pd installation, but there is an extra folder containing things like bob~ and bonk~.) Now I can create [cyclone/avg~] (and even simply [avg~]), and its help file looks as it should, without errors.

I had previously saved externals to a separate folder outside of the Pd installation, but I'm inferring that's not a good thing to do. So I'm in the process of moving them all into Pd/extra and removing them from the Pd search path.

As noted elsewhere on this forum, a confusing thing is that different externals seem to have different ways to gain access to their objects. It's not clear when a declare object is needed or which flag should be used on it.

Now I'm testing the chaos external. I can create {chaos/base3], for example, but when I open its help file, I get "couldn't create" errors. Different variations of the declare object didn't seem to help.

@alexandros

I wish I thought of this when starting out, but have come to this conclusion over time too, learning the hard way.

But now, having literally thousands of patches, using direct references to externals, without the " cyclone/xxx " prefix, it just seems like a humongous task to change it for all patches. But yeah, should probably do it, to make it easier to find which externals packages is actually used. Have already had issues with that when making patches on Osx and using them on Linux systems.

Another example to why it's good to use external prefixes, like " cyclone/xxx ":
If I create a abstraction called " scale " and try to load it, it actually loads a cyclone object called " scale " and not my abstraction.

So using the prefix for externals gives us more freedom for naming abstractions, like " scale " and it won't cross reference to, for example, cyclone external library

@plusch I don't think it's a good idea to manually put stuff in Pd/extra. What's your OS? Don't you have a Documents/Pd/externals folder? Usually deken creates this folder for you, or something along these lines. It's better to put things in your user environment rather than in your system environment.
I don't know about the chaos library. Is it a collection of objects (many .c and .pd_linux, .d_fat, or .dll files, according to your operating system) or is it one monolithic library with one .c file and one executable? In the case of the latter you'll have to import the library, e.g. [declare -path /path/to/chaos -lib chaos].

@jaffasplaffa I second that.

@alexandros: Ah, I misunderstood you. When you originally referred to Pd/externals, I thought "Pd" meant the folder where the Pd program was installed.

My OS is Windows 10.

The defaults in File > Preferences > Path are
Pd Documents Directory: C:/Users/paul/Documents/Pd
Externals Install Directory: C:/Users/paul/Documents/Pd/externals

But because I was running low on space on my C drive, I had changed mine to
Pd Documents Directory: F:/Pd_patches
Externals Install Directory: F:/Program Files/Pd_externals

So I think you're saying that those directories on my F drive should be acceptable. Is that correct?

@plusch The usual folder structure in windows is a top folder called Pd.
If installed it will be in the Program Files or Program Files (x86) folder.
The contents look like this........

The bin folder contains the Pd executables Pd.exe and Pd.com
Usually Pd.exe is the program started when a patch is opened.
Anything in the bin folder will be found by Pd when it starts.
The wish program is in there...... it does the heavy lifting..... the console window and calls all the GUI stuff that is in the tcl folder.

Pd also knows to look in the doc folder as all the help files for vanilla objects are in its sub-folder "5.reference".

Pd also looks in the "extra" folder for externals.
But only as they are created.
Once it has found an object it remembers (until it is shut down) and doesn't need to search again.
So most libraries in the extra folder (and their help files) will work straight away.

But not single binaries...... some libraries just have a single binary that contains all its objects.
The problem is that an object in a single binary cannot be found by its name........ for example pix_video does not exist as a binary.......... it is wrapped up in the Gem binary.
A command........ -lib Gem...... must be added to the Pd startup preferences "Startup Flags" box.
The Gem single binary is then loaded as Pd starts and it has then already found all the objects.

If you install libraries elsewhere Pd cannot find them unless the whole path to the library is added to Pd Path Preferences.
And if it is a single binary that is also true....... and it will also need the -lib flag and to be added to the flags.

Although this behaviour causes a lot of "cannot create" problems when libraries are not installed to the extra folder it is useful as mentioned above when you don't want Pd to find an external....... or more especially you want to limit where Pd looks for objects so that it does not find other abstractions with the same name.
It also allows you to run many different releases of Pd without them interfering with each other if you don't actually "install" them....... but just put them in a folder somewhere.

BUT....... the Pd path and startup preferences are stored in the registry........ separately for 32 and 64 bit flavours. So all 64-bit versions will share their preferences settings (and 32-bit theirs).
The way around that is to start Pd from a batch file that specifies paths and flags...... then each release can be completely separated.
Batch files can also specify the other Pd command line flags....... so you can also set up different soundcards for example specifically for each Pd.exe.

David.

@jaffasplaffa said:

But now, having literally thousands of patches, using direct references to externals, without the " cyclone/xxx " prefix, it just seems like a humongous task to change it for all patches.

No need.

I teach my Pd students: 1/ Never add an external to startup or search paths. "Pd/externals" is a default search path, nothing else. No startup paths. 2/ Always use the [declare] object.

Once you [declare -lib cyclone], then it can find cyclone objects without a prefix, and the patch includes built-in documentation of which externals it needs.

hjh

@whale-av Thanks for the detailed write-up. I will refer to it as I try to think of a coherent process for managing and using externals so that the help files will open without "couldn't create" errors.