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.
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.
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>].
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