[PD] Best practices for [declare]

Winfried Ritsch 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

@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 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 mailing list