[PD] Best practices for [declare]
ritsch at iem.at
Fri Feb 26 10:51:40 CET 2021
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
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
external-libs // .dll, .pd_darwin, .pd_linux, ....
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
Some externals add their path on loading the binary like "zexy", others like
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 ]
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" '
(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
> # 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:
> 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
> 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
> # 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
> For posterity, the full background on this feature is here:
> > On Feb 26, 2021, at 12:58 AM, pd-list-request at lists.iem.at wrote:
> > Message: 3
> > Date: Thu, 25 Feb 2021 23:48:23 +0000 (UTC)
> > From: Sebastian Shader <sebfumaster at aol.com <mailto:sebfumaster at aol.com>>
> > To: "pd-list at lists.iem.at <mailto:pd-list at lists.iem.at>"
> > <pd-list at lists.iem.at <mailto:pd-list at lists.iem.at>> Subject: Re: [PD]
> > Best practices for [declare]
> > Message-ID: <2025038600.476357.1614296903882 at mail.yahoo.com
> > <mailto:2025038600.476357.1614296903882 at 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/>
- ao.Univ.Prof. DI Winfried Ritsch
- ritsch at iem.at - http://iem.at/ritsch
- Institut fuer Elektronische Musik und Akustik
- University of Music and Dramatic Art Graz
- Tel. ++43-316-389-3510 (3170) Fax ++43-316-389-3171
More information about the Pd-list