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.

@60htz The path seems not to have been normalized in vanilla as it was in extended.
Tk 8.6 still normalizes paths, so I don't see why it has been dropped for new files.
That is the only difference I can see straight away.
You could try re-inserting normalize....... in pd_menucommands.tcl

 if { ! [file isdirectory $::filenewdir]} {
        set ::filenewdir [file normalize $::env(HOME)]`

David.

Thanks @ingox , I tried adding file normalize $::env(HOME) but always the same errors at start;

#X: no such object

I think the good old pd "filename" command was replaced by a far less flexible pd "menunew" command

@60htz Ok. This will declare the paths......... declare.zip ..... adding them to the path preferences only if they do not exist.
It's a plugin, so put the file somewhere already in Pd search directories..... but the only folder you can be certain of being searched (even when prefs have been deleted) is the "extra" directory....
It will then run every time Pd is started. The Path Preferences will be saved automatically.
For some unknown reason the procedure called is absent from Pd 0.47-1..... so it will not work for that version unless it is added. For other versions it is in "wheredoesthisgo.tcl".

You can add a new menu button of your own like this........
https://forum.pdpatchrepo.info/topic/9991/woof-a-new-window-menu-for-vanilla-tcl
see "woof.zip" ....
Change pd_menucommands.tcl and pd_menus.tcl where you see "woof" and then build your own menu items. Maybe best to do the changes to your current vanilla as those tcl files might have changed since Pd 0.46-7
David

Thanks @whale-av, it looks to be a great solution!
Unfortunately it doesn't work on my pd...

I can see that the paths are added to the paths preferences window with the plugin, but my abstraction still couldn't create untill I add a [declare -path mypath] object!

Strange...

@60htz Yes, very strange.
What version of Pd and which OS?

Stupid question maybe........ are your files actually in Pd/extra/extra/path1 and path2.....?
David.

Yes @whale-av, I used pd 50.0 and put the files in the correct folders "extra/folder1 extra/folder2"

@60htz You can maybe create a hidden file via TCL, send the declare message to that file and only afterwards load the actual file. The idea is that the path would be declared when the actual file loads. This code could create the hidden file:

set hiddenPatch [open ".hidden.pd" w+]
puts $hiddenPatch "#N canvas 374 215 301 188 10;"
pdsend ".hidden.pd declare -path extra/folder1/"
close $hiddenPatch
file delete .hidden.pd

This is not tested and can contain errors. Just an idea

@60htz It works for me with Pd 0.50 in windows7.
I assume you modified the plugin for those folders.
What is your operating system?
@ingox I think Pd now only sets a [declare] in an abstraction for that abstraction..... I need to check that though. Maybe your solution could work though....... as Pd might see it as a top level "mother" patch. Testing required by @60Hz though.
David.

@60htz Just a chance...... declare3-plugin.tcl
It sets the paths as before.
It then creates a pd file in the bin folder "declared.pd" that contains the declare lines......

#N canvas 0 0 900 600 12;
#X declare -stdpath extra/path1;
#X declare -stdpath extra/path2;

It then opens the file but doesn't show it.

I cannot test because the "declare-plugin" I posted above worked on my system.
Opening a new file and putting one of your abstractions will tell you right away.
Anything broken can hopefully be fixed by deleting the plugin.
David.

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