[PD] Preferred/best practice for loading external objects

Winfried Ritsch ritsch at iem.at
Wed May 4 15:27:27 CEST 2016


Deken is really great, but spams my linux home, everytime I load an external.

I suggest since it is now official in vanilla, we should refine now were to 
store/load externals in linux/debian for future compatibility.

I know it is not deken, but Pd which delivers the paths, but on Standard Linux 
system which respects 


it should go under .local/share/puredata   or .local/lib/pd/ or for old style 
.pd/ but not on $(Home)/pd-<something>.

So two solution: 

a) Deken should not take just pathes from pd but try preferred ones and add 
pathes to pd on startup

b) Pd suggest as first writeable pathes among others non user-writeable:
  /var/lib/pd        (group puredata set)
  /usr/local/share/pd,  (group puredata set)

and deken decides: if the parent dir is writeable it create it and uses it.

so if no ./local it would not take it, but the next suggestion and if in the 
puredata group which can write to /var/lib/pd take this or

c) deken at least ask where to write it


Am Mittwoch, 4. Mai 2016, 13:30:56 schrieb IOhannes m zmoelnig:
> On 2016-05-04 10:56, Antonio Roberts wrote:
> > Now that Pd vanilla + deken is the preferred way to have a
> > Pd-Extended-like experience I was just wondering if there are any best
> > practices or preferred way for loading objects from externals.
> > 
> > Should we reference the external i.e. [mrpeach/binfile] or just load
> > it in our startup path and use [binfile]. The former has the advantage
> > of giving a hint to what externals are needed but results in long
> > objects.
> > 
> > Any suggestions?
> *my* suggsetion is to use [declare]
> fgamsdrt
> IOhannes

Ritsch, Winfried, Ao.Univ.Prof. Dipl.-Ing.
   Institut 17 Elektronische Musik und Akustik
   8010 Graz, Inffeldgasse 10/III
E-Mail 	ritsch at iem.at
Homepage 	http://iem.at/ritsch
Mobil 	++436642439369

More information about the Pd-list mailing list