So I'm finally catching up to the [declare] best practice. (The driver was providing Pd and external binaries to one of my colleagues, to install in the media lab, where I don't really have confidence that the search paths and startup libraries would be set correctly in Preferences -- so, to simplify the installation, I had them only add Pd/externals as a search path and I will tell the students to use [declare] for all externals. -- I think this is better, FWIW -- I was getting tired of objects not loading because I had forgotten about dependencies.)

But I discover that, in Windows, the help browser doesn't show any help files in subfolders under Pd/externals, and it doesn't show externals that have been declared. (In Linux, subfolders are visible though -- so maybe it's just a Windows bug.)

The help browser is especially useful for Gem and other large external packs, where I might not remember the exact names of objects (and, for that matter, to help browser is really useful for finding objects that you didn't know about).

How to handle this? (Browsing help in the system's file browser isn't an especially lovely solution.)

hjh

@ddw_music Yes, this is a major downside of the declare method. Help files will only show up with the old path method.

This would be an issue worth to discuss on the mailing list.

@ingox "Yes, this is a major downside of the declare method. Help files will only show up with the old path method"

Or maybe just log a bug report, then.

Curiously, though, in Linux it does show help files in subfolders. So I suspect that maybe the subfolder search is being done incorrectly in Windows (which would make sense, since Windows decided back in the day to be contrary and use \ as the path separator, creating headaches for decades thereafter -- if Pd is searching for help files on the assumption that / separates folder names in paths, that would explain what I'm seeing).

hjh

@ddw_music On my Linux machine, the help files won't show up in the patch browser if i only use [declare].

@ddw_music what do you mean by "Pd/externals" on windows? what is the full path?

Do you mean the new directory that pd prompts the user for when deken is run? Are you sure that you didn't add this path to the search paths when prompted in both Windows and Linux? Because from your description it seems most likely that it was added to the paths on Linux but not Windows. (You can check the "paths" in preferences to see)

The helpbrowser displays everything in the static paths (of which this directory is not a part) and also the user paths (of which it is a part if the user agrees when deken prompts for it)

It takes 10 minutes to boot that machine, but OK, here are the screenshots.

On my Linux machine, I have this. (Startup preferences are empty.) E.g. Gem is not listed under either "path" or "startup," but it does appear in the help browser.

On my Windows machine -- observe -- "Externals Install Directory" is the same as the single search path (specific path is not the same as in Linux, but the configurations are functionally identical), and at right, you can see that under Documents/Pd/externals, Gem and a couple of others live here.

But the help browser omits Gem and zexy.

Because from your description it seems most likely that it was added to the paths on Linux but not Windows.

No, that isn't it. Functionally equivalent configurations, different behavior = platform-specific bug (IMO).

hjh

@ddw_music Are you looking at the same directory?
If you have multiple copies of Pd a newer download can still be pointing at the directory of a previous one in the path preferences...... as the registry entry is shared.
Maybe a stupid question as I am win7 only and maybe the "This Pc" is a system shortcut to "/Users/gary8" in later versions.
But I cannot imagine that some folders would not be listed in a directory listing.
David.

@whale-av

Are you looking at the same directory?

Do you mean the Linux machine or the Windows machine?

If the Linux machine -- I'm aware of the ~/.pdsettings file -- its contents match the display (nloadlib = 0 meaning no startup libs, npath = 1 and only a path1). There is no registry in Linux, so that comment isn't relevant to the Linux machine.

On the Windows machine, there isn't any other Pd library folder, and I keep only one version of Pd. But I don't think this question quite makes sense -- if there are multiple versions of Pd sharing the same settings, how would the two versions behave differently? Wouldn't I see the same behavior in multiple versions?

FWIW, I checked the registry and, just like the Linux machine, nloadlib is 0 and npath is 1. So Pd on the Windows machine should not be loading any startup libraries (and indeed, I don't see any output from Gem or zexy), and there should be only one search path (which I can confirm by creating an object in a subfolder, and it isn't found).

"This Pc" is pretty clearly just a display convention in the Windows Explorer, and has nothing to do with the actual file system structure.

hjh

As a further test -- I hacked ./tcl/helpbrowser.tcl to print to stdout some progress messages while building the help browser directory list. (Doing this in Linux -- I haven't set up the Windows machine to build Pd from source.)

To my surprise, I found that the Externals Install Directory is part of $::sys_staticpath (in Linux).

Each entry in $::sys_staticpath is globbed for any subdirectories -- so this is how it's finding Gem, cyclone, zexy etc.

staticpath add search /home/dlm/pd-externals/Gem
staticpath add search /home/dlm/pd-externals/freeverb~
staticpath add search /home/dlm/pd-externals/zexy
... etc.

A little bit later, it checks $::sys_searchpath -- this comes from preferences. These entries are not globbed for subdirectories.

searchpath add search /home/dlm/pd-externals

(Above is the only entry coming from Preferences > Path.)

So one possible difference is that the "static path" includes my external location in Linux (that isn't speculation -- the stdout listing proves it), while it probably doesn't in Windows.

OK, then, let's grep staticpath... this leads to s_path.c, which says (in an ifdef for Linux):

sys_expandpath("~/pd-externals", pathbuf, MAXPDSTRING);
STUFF->st_staticpath = namelist_append(STUFF->st_staticpath, pathbuf, 0);

So user-home/pd-externals is a special, hardcoded location for Linux, which I happen to be using for my externals.

Looking a bit further down, hardcoded locations in Windows are AppData/Pd and something about common-program-files/Pd -- but the Pd GUI recommends Documents/Pd/externals as the installation directory. (And Mac will have a similar problem, because the hardcoded locations include ~/Library/Pd but again not Documents/Pd/externals.)

I'm satisfied that this explains the difference in behavior between the two environments. But it leaves a bit of an impression that this hasn't been completely thought through. If there are magic locations for help browser search, ideally this would be coordinated with recommended installation directories, but they aren't.

hjh

@ddw_music Glad you found it.
My mistake in the previous post not noticing that you had accessed the help browser..... but the help-browser is set to look only in the "extra" folder unless paths are added in the preferences pane.
But the point still stands if you have more than one version of Pd on your computer..... it is best to name them as the shared registry paths could be looking at a different flavour of Pd.
See x4.htm in the Pd/doc/manual for all information about Pd objects, externals, user directories, library types (single and binary) and search paths.
The magic location is the "extra" folder.... as it always has been.
David.

@ddw_music well I for one have never been on board with the whole ~/Documents/Pd/externals thing.. especially if it is not in staticpaths (also why would you install externals into Documents of all places??). I do think that ~/pd-externals is supposed to be different from ~/Documents/Pd/externals though (that was your main hangup I think). To me it makes sense that windows has appreciably different standard paths than linux.

This isn't so much an inconsistency between the gui prompt and the helpbrowser as it is an inconsistency between the gui prompt and the static paths themselves (which the helpbrowser then references when it populates its listboxes)
if it were up to me externals would still be installed in an "old" standard location by default - e.g. ~/Library/Pd on osx - and the gui wouldn't recommend anything different, maybe just tell the user what directory externals will be installed to and ask if they want to change it.

I assume you can navigate to the externals directory in the help browser in windows and Gem and Zexy show up there though..

just fyi you can safely delete your /home/dlm/pd-externals entry from the search paths as it is already in the static path. (then it won't show up in the helpbrowser anymore, which is redundant since the helpbrowser is populated with its contents anyhow)

on the other hand, I suppose one could use ~/Documents/Pd/externals as a way to disclude items from the root helpbrowser listbox.

@seb-harmonik.ar

To me it makes sense that windows has appreciably different standard paths than linux.

Sure. And I can see the logic of installing executables into locations that are ordinarily hidden -- but, I'm guessing that the reason why the default external install directory is in Documents for Mac and Windows is that the user may need to manipulate the contents of this location, and that gets harder when the OS's file browser goes out of its way to make it hard to find them. In Mac (I think), Library used to be visible, but then Apple decided there was more money to be made by marketing lifestyle devices to ordinary consumers rather than supporting media professionals, so... hide it. In Windows, AppData is likewise hidden.

I assume you can navigate to the externals directory in the help browser in windows and Gem and Zexy show up there though..

Ah, OK, I overlooked that -- in hindsight, I probably shouldn't have overlooked it, but... anyway, yes, I checked the Windows machine too, and there is an "externals/" entry and all the good stuff is under there.

So that is... actually the solution!

Thread resolved. Thanks!

hjh