Yes me too: I am happy with the declare object as is,
... since I don't know a better solution. ... don't use -stdpath -stdlib anymore in new projects
@Dan: The numbering for order is a nice idea, anyway editing a declare object is as fast (or faster) than open an dialog and settings some things somewhere. Maybe as an option -P <n> (priority from 1 to 32768 ;-)
lets talk "best practices", here is mine:
We have to think of use cases, when it comes to "structured Pd coding" (1) and
for example here: distribute an "Pd App" as folder for different OS and
computers (where we don't know which libs are installed where I don't want to
care) and organized like (example see: vrr.iem.at )::
project // to be distributed
- abs // abstraction and subpatches for application
- data // settings, sounds, tables...
- doku // manuals etc...
- lib // local libraries for project
-libs // external libraries: local cleaned and multi-OS-ifyd
- library-A
- abs
- examples
external-libs // .dll, .pd_darwin, .pd_linux, ....
- library-B
- src
- abs
main.pd // main dsp should wor headless also
gui.pd // gui patch used by main.pd and remote
remote.pd // remote control patch ....
...
in libs: libraries included in releases distribution, empty in git with a "readme".
Some externals add their path on loading the binary like "zexy", others like iemlib don't.
so here the declares as example for vrr which work now:
[declare -path . -path abs -path data -path libs -path libs/acre -path acre -path libs/aoo -lib aoo -path libs/iemnet -path iemnet -path libs/iemlib -path iemlib -lib iemlib -path libs/zexy -lib zexy ]
My workflow: Doing a main.pd and adding in [pd settings] declares, by adding project paths and then copying declares from library examples. Afterwards I have the to combine in one declare statement for -path and -lib statements or else it doesn't find them. For better reading of the code (and remote debugging help if the app doesn't work somewhere on a computer) it would be fine to have them structured in separate declares, ... since "-path" is Pd version of C's ' #include "header.h" '
mfg winfried
(1) this should be an own thread
Am Freitag, 26. Februar 2021, 01:59:23 CET schrieb Dan Wilcox:
Honestly, I'm not going to rehash *all* of the discussions about paths, but I do feel like writing some perspective, at least as far as I see it as a user, someone who has taught Pd a bit, and someone who has now worked on it.
# Standard Paths
What I will point out is that, in most ways, "standard path" is a misnomer in Pd.
These we originally added as essentially hardcoded search paths:
https://github.com/pure-data/pure-data/blob/master/src/s_path.c#L243 https://github.com/pure-data/pure-data/blob/master/src/s_path.c#L243
Linux: ~/.local/lib/pd/extra/ ~/pd-externals /usr/local/lib/pd-externals
macOS: ~/Library/Pd
Windows: %AppData%/Pd %CommonProgramFiles%/Pd
And I believe Pd's own bundled "extra" path is one of these as well.
"Hey that's great!" says everyone "Now I can just plop things in there!"
...except that things change over the years.
The "Library" folder in the macOS user home folder has been hidden by default for some years now. Whoops, easy to find place gone for Mac people. "Oh but they can just put stuff in extra" ...except that "extra" is located INSIDE the macOS .app bundle, so now we need to ask beginners to literally OPEN an app they download and add files INSIDE. Hmmmm not scary at all?
For Windows people, where is that again? Kind of obscure for some people as well.
Linux makes the most sense, but how many users want a "pd-externals" folder in their home folder and how many beginners are going to navigate to /usr/local/lib/pd-externals?
# User Search Paths
So moving forward, people can add their own user search paths aka not one of the hardcoded "standard paths" which are mostly obscure / hard to find for beginners. Then they can define their OWN place to plop externals. Great!
...except that beginners have to manually create their own folder, add it to the user search paths, and then it works. How many people do this right on the first go? Maybe not a big deal, but another stumbling block.
# Deken
As Pd-extended slowy dies out, deken is introduced to help with decentralized externals. Great! We have a tool to help download and install pre-buitd externals.
...but where do we put them? Originally, deken downloaded to the bundled extra folder because it was the only "standard path" known to exist on all systems. Great!
...except macOS people STILL are downloading and installing things INSIDE the Pd .app bundle. So when you delete the .app and replace it with a new version of Pd, you've lost all of your externals and you may not know why if you've only ever downloaded things with deken.
Sure, you can specify a deken download location but it's yet another step to ask beginners to have created such a location, add it to their user search path, AND specify that deken should use it. I think the early versions of deken, you had to manually choose the download location on EVERY download.
# Documents Directory
After prodding from other Pd users on this list who also teach Pd, the Documents Directory was added as a helper to create a user search path for both beginners to use AND provide a default deken download location (~/Documents/Pd/externals) which is also added to the user search paths on creation. Beginners now have a basic place to start with and externals downloaded form deken should be found via declare.
The ~/Documents/Pd location was chosen as it mirrors the locations chosen by various other "creative coding" environments such as Processing (~/Documents/Processing) and Arduino (~/Documents/Arduino). If the documents directory is enabled, Pd GUI dialogs also open here by default instead of in the user home folder.
This is not a replacement for the previous "standard paths" but sort of a "super user search path" that can be created for you, if you want.
If you hate this, you can click NO when it asks or disable it in the Paths preferences, and curse me as I wrote the plugin which provides this functionality.
For posterity, the full background on this feature is here: https://github.com/pure-data/pure-data/pull/152 https://github.com/pure-data/pure-data/pull/152
On Feb 26, 2021, at 12:58 AM, pd-list-request@lists.iem.at wrote:
Message: 3 Date: Thu, 25 Feb 2021 23:48:23 +0000 (UTC) From: Sebastian Shader <sebfumaster@aol.com mailto:sebfumaster@aol.com> To: "pd-list@lists.iem.at mailto:pd-list@lists.iem.at" <pd-list@lists.iem.at mailto:pd-list@lists.iem.at> Subject: Re: [PD] Best practices for [declare] Message-ID: <2025038600.476357.1614296903882@mail.yahoo.com mailto:2025038600.476357.1614296903882@mail.yahoo.com> Content-Type: text/plain; charset="utf-8"
why is it that using standard install locations isn't encouraged (or rather, why did it move into Documents of all places?)
Dan Wilcox @danomatika http://twitter.com/danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/