On 2017-07-29 15:42, Roman Haefeli wrote:
On Sam, 2017-07-29 at 11:35 -0600, jmejia@anestheticaudio.com wrote:
Going through Alex's excellent documentation made me think about how nearly every single new PD user I encounter struggles with OS specific problems when it comes installing externals. As a teacher who introduces a lot of new people to PD - I see this a LOT.
I hear you.
The standard place for putting externals on OSX (~/Library) is hidden by default - and various versions of OSX require various ways of un- hiding.
Yeah. But why is unhiding necessary in the first place? From what I understand, Deken suggests the first writable search path it finds, so the user usually doesn't need to do anything at all but let Deken download the external to the right place.
Unhiding is necessary in order to make the required ~/Library/Pd. It has no writeable path on a default OSX install.
The problem here is simply that there needs to be a standard path that Pd searches for that is also considered userspace by OSX.
Similarly the windows path is hard to find - and permissions and view settings need to change to make that folder as well.
Entering '%appdata%' into windows explorer is not _that_ difficult, but I agree with you anyway. I don't see why you need to change permissions or view settings. %appdata% directs you to the user-specific (thus user-writable) application data folder.
So even once the users understand they need to *make* a folder - their OS stops them from making it in the right place.
Yes, this is clearly user-unfriendly. It's a contradiction not to create the right directory and force it to be located in some hidden place. That's why I'm a proponent of automatic search path directory creation (at least the user-specific one). At least on Linux, we're already there: If Deken doesn't find a writable path, it suggests to create ~/.local/lib/pd/extra and - if confirmed - puts externals there.
You may be right about windows - I have less experience with that... maybe it was just user struggles with figuring out what %appdata% even means.
Auto creation of a folder would be fine with me - but I've seen a lot of resistance to that idea. I think simply having ~/Documents/Pd in the list of standard path's would solve this problem in a big way!
Your experiences might stem from Pd 0.47.1 where Deken did _not_ create any directory automatically. I think the best people can do now is to report specifically when Deken does not do something sensible per default. By 'sensible' I mean that the downloaded external is extracted to one of the search paths, so that it can be loaded with [declare -stdlib <external>] or [declare -stdpath <external>].
I'm definitely talking about a current situation. On a default installation of OSX, deken has no useable place to install - and you can not install externals. My process, and the process I have taught others is to google for the paths.. and then google for your OS specific ways to un-hide ~/Library - the directory you need to see in order to create the Pd folder.
If Deken does always behave in a sensible way, then there isn't a strong necessity to have a more user-visible search path, or is there?
Roman _______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list