On 2018-09-01 13:05, rolfm@dds.nl wrote:

@IOhannes

...

On 8/31/18 11:56 AM, rolfm@dds.nl wrote:

...

still, the searchpath-preferences are apparently different for externals and for plugins.

i missed how the "plugins" (i assume you mean the extensions for the Pd-gui) entered the discussion here.

i don't know how to interprete this remark.

as in: "i (IOhannes) am confused, because you haven't yet used the term 'plugin' in this thread, and i'm not sure whether you mean GUI-plugins or something else". 'plugins' is a quite generic term, but from the rest of your mail i now gather that you mean "plugins to extend the Pd-GUI functionality" (which I called "GUI-plugins")

in the Pd-console i get this output:

loaded iem::punish::patcherize-plugin loaded iem::punish::triggerize-plugin 'deken-plugin.tcl' already loaded, ignoring: 'D:/pd-0.48-1.msw/pd/extra/deken-plugin/deken-plugin.tcl' patcherize - turn objects into a subpatch triggerize - insert [trigger] ad lib.

for the plugins first the standard folder is inspected and after that the (changed) path in my preferences

the problem here is, that i don't know where you've installed Pd (what you consider a standard folder) and which path you added in your preferences.

there is no choice here for the user; besides removing (temporarely) unwanted plugins from the standard folder.

yes.

• GUI-plugins are only searched for at startup time (therefore you canot

load GUI-plugins with [declare])

• the search-paths are (as always) searched for in this order
  1. search-paths passed with "-path"
  2. search-paths saved in the preferences
  3. system search-paths
  3.1 user specific 3.2 system specific 3.3 Pd-specific
• whenever a GUI-plugin is detected (doing a simple filename match), it

is loaded (or at least, an attempt is started).

the only way to disable a GUI-plugin is by moving it out of the search-path.

there used to be a GUI-plugin that would provide you with a nice clicky-interface to enable/disable other GUI-plugins (by moving them in to /out of a non-searched path.

...

...

BTW is there a way to declare a .pdsettings in the command-line? (i cannot find one).

$ pd -help 2>&1 | grep -i pref -prefs           -- load preferences on startup (true by default) -noprefs         -- suppress loading preferences on startup -prefsfile <file>  -- load preferences from a file

thanks for that. trying this out i found: the -prefsfile option does 'replace' the preferences. the 'load from..' in the preferences menu adds the prefs from the file to the existing ones.

Pd is not good at undoing system-wide settings. e.g. once you've loaded a library, you cannot unload it. this makes it quite complicated to "replace" preferences from the menu (as a lot of preferences have already been applied non-reversible).

it's different from the cmdline (where you start with a pristine state). it would be nice, however, to be able to load multiple preferences files (and also so stack them, e.g. to specify a secondary prefs-file inside the currently loaded one)

fgmasdr IOhannes