[PD] Preferred/best practice for loading external objects
msp at ucsd.edu
Wed May 4 18:46:04 CEST 2016
I agree this is a problem. On my machine, selecting (for instance)
freeverb~ from the deken plug-in creates a directory
~/pd/extra/freeverb~ which would be a good place to put it except for
the fact that that is my git repo (I then have to move it or else I'd
end up publishing freeverb~ in vanilla!).
I think deken should always query the user whether it's OK to install
into the directory it's planning to install to. Indeed, in the function
::deken::clicked_link I see an appropriate line:
set ::deken::installpath [tk_chooseDirectory \
(etc) but this never got called when I downloaded freeverb~. I can't
figure out why this isn't getting called. Can anyone suggest a way I
can get deken to always confirm where it will install?
On Wed, May 04, 2016 at 03:27:27PM +0200, Winfried Ritsch wrote:
> 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
> Pd-list at lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
More information about the Pd-list