For some workshop, I am tuning tcl settings so I can give every students a pd with libs and special gui menu. In the pd-extended era, I was simply modifiying the command "New" in pd_menucomands.tcl so it would add thoses lines:

pdsend "pd filename $untitled_name-$untitled_number [enquote_path $::filenewdir]" #create new patch
pdsend "#N canvas 0 0 900 600 12;"
pdsend "#X declare -stdpath extra/path1"
pdsend "#X declare -stdpath extra/path2"
pdsend "#X obj 0 0 path/menu_bar" #menu object
pdsend "#X pop 1"

The patch was created and saved with the paths inside the pd file; and no [declare] object was visible, hence, no path object deleted by mistake by user: perfect magic trick.

Now, many things have change in Vanilla pd. The "filename" command disappears replaced by "menunew".

So I need to do:

pdsend "pd menunew $untitled_name-$untitled_number [enquote_path $::filenewdir]" #create new patch
pdsend "#X declare -stdpath extra/path1"
pdsend "#X declare -stdpath extra/path2"
pdsend "pd-$untitled_name-$untitled_number obj 0 0 path/menu_bar" #menu object

But Why the path trick doesn"t work anymore?

When hit the New patch it works but the console say:

#X: no such object
#X: no such object

Is there a way to include the path without adding many objects [declare] automatically for every patch created? I know that I can use a .sh script with path flags but I prefer to keep this way so the native menu "New" of pd will add my special paths in every .pd files created, and add my menu object.

@whale-av said:

declare3-plugin.tcl

That's interesting, I tried it and have //extra/patch1 and //extra/patch2 added in search paths.

But Pd mouse change to a clock on my system and when I go to path preferences panel, the forms are frozen.

Maybe it's a bit heavy!

Right now, the only way I found to to make it work, is to automatically adding [declare] objets in the background for every new patch created. But I don't like this method...

pdsend "pd-$untitled_name-$untitled_number obj 0 0 declare -stdpath path/path1"
pdsend "pd-$untitled_name-$untitled_number obj 0 0 declare -stdpath path/path2"

@60htz You can also send the message for the Path settings dialog:

pdsend "pd path-dialog 1 0 +/home/ingo/Documents/Pd/externals"
pdsend "pd save-preferences"

This way you write the path into the Path settings. This will stay after Pd has been closed.

You can make
[r pd]
|
[print]
and open + save any dialog from the menu to see the message it is sending to Pd.

@ingox said:

pdsend "pd path-dialog 1 0 +/home/ingo/Documents/Pd/externals"
pdsend "pd save-preferences"

Another bright idea! But I need to be able to use relative paths and it works only with full paths here.

@60htz Since you already deliver a modified version of Pd, could you not add a modified link to a batch script that determines the absolute patch and then opens Pd with the path startup flag?

@ingox That would be also possible, but when people double click on their .pd files, they won't use the script and all objets won't create this way.

So I am still searching a good solution to include paths in my .pd files other than creating many [declare] in my main .pd patch.

Also, using verbose, I found out that (at least on OSX), pd's search paths from preferences will never be prepended to known path.

Exemple:

If I have /path1 in my search path, pd will search in every known user path AND for /path1 but never tried all/knownpath/path1

That's why it doesn't work with your declare-plugin.tcl, wich would be perfect for me :/

@60htz Do you have wheredoesthisgo.tcl in your pd/tcl folder?
If so could you zip and upload it to this thread please.
David.

Sure, here it is wheredoesthisgo.tcl

@60htz Ok..... will have to do more research. The file is identical to the one I have in windows...... so contains the same routine.
The original declare plugin I posted....... declare.zip produces this.........

and will immediately find an abstraction in the added paths........ as the complete path is added.
There are spaces in my paths....... and it still works so that is not a cause, when it could be in windows.
Do you have spaces?
Need to look at how OSX treats paths.......
David.

@60htz If you use the plugin, do the new paths get stored in "~/Library/Preferences/org.puredata.pd.plist"...... ?
and if so do they look in some way different to other paths saved there?
David.

This is what I have with

set path_list "/extra/path1 /extra/path2"

In the declare-plugin.tcl

And here is my plist file org.puredata.pd.plist

Maybe it's a path problem in OSX?

Unchecking "Use standard paths" is the same, but it is checked by default.

@60htz Sorry...... maybe we will get somewhere but I need your help for testing.
New plugin....... declare-plugin.tcl
It just prints the path that it returns to the Pd terminal.
Open Pd and search (Find menu) for "path" please...... let's see what it is trying to send.....
Mine obviously prints.......

Resulting Path >>  C:/Users/David/Desktop/Pd Vanilla/pd-0.50-0 portable.msw/pd-0.50-0/extra/path1
Resulting Path >>  C:/Users/David/Desktop/Pd Vanilla/pd-0.50-0 portable.msw/pd-0.50-0/extra/path2
`

Thanks for trying to help
This is what I've got:

Resulting Path >>  //extra/path1
Resulting Path >>  //extra/path2

@60htz Good..... that narrows it down..... progress at last.
[pwd] in tcl was around in 2007.... so not sure why it is not returning the current path in osx..... but we will find out.
David.

@60htz Again with a search for "path" in the terminal please....... declare-plugin.tcl

@whale-av

New Path >>  //extra/path1
New Path >>  //extra/path2

@60htz [pwd] seems to be the culprit.
This still works in windows and my fingers are crossed.......... declare-plugin.tcl
Search for "Current" and "Path" afterwards......... although they should be grouped together.
David.

@whale-av

Great!
That's working now, you were right pwd was the culpid. Thanks, it works well now

I think I owe you a beer