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.
The standard place for putting externals on OSX (~/Library) is hidden by default - and various versions of OSX require various ways of un-hiding.
Similarly the windows path is hard to find - and permissions and view settings need to change to make that folder as well.
So even once the users understand they need to *make* a folder - their OS stops them from making it in the right place. It would be great if that os specific stuff was included - because it's a major stumbling block for a lot of new users.
This can be sort of mediated with by a bunch of clear and easy to find OS specific instructions - but that's hard when OSX keeps changing things etc. I'm happy to write these if that's the best course of action.
Basically it means you need to get deep with your OS, and probably do some google searches to figure out how create a folder in protected system space before deken is actually useful.
Most similar software uses unprotected user space as a default place for installing external libraries. /Documents/Max7, /Documents/Processing/Libraries - etc.
Could we add a location like this to PD's standard search path? Then users could create the folder without jumping through a lot of hoops with their OS.
I understand that users can add a path like this manually - but that's an additional hurdle - and since deken is so tightly integrated, it doesn't seem like that should be necessary. It also causes confusion when you move paths across systems.
Thanks for your input. This is a recurring topic that me and others have pointed. I've made simple suggestions that'd take care of most of this, including one of yours, but found resistance.
Now, some of the feedback, unexpectedly, led me to suspect much of the resistance comes from not actually getting the issue in the first place! Thus, an underlying issue may be that there's not a clear picture and consensus about Pd's fundamental structure. So perhaps that needs to be sorted out before aiming for improvements.
To be more specific, you mention issues related to Pd's current "Standard Paths", given that it is clear to you that this is the best practice for externals. Surprisingly, that is not a consensus between developers.
Hence, I when posting my documentation in the other thread (linked here https://lists.puredata.info/pipermail/pd-list/2017-07/119753.html), I opened it up for discussion to see if what I had there was in fact a consensus or not. Namely, if "Standard Paths" were the canonical way of installing externals or not. So far, 5 of us agree it is and share this same view. Nonetheless, believe me, not everyone shares it. But I'm hopeful we'll sort it out one way or another. It's to the interest of all.
2017-07-29 14:35 GMT-03:00 jmejia@anestheticaudio.com:
I understand that users can add a path like this manually - but that's an additional hurdle - and since deken is so tightly integrated, it doesn't seem like that should be necessary. It also causes confusion when you move paths across systems.
"User added search paths" are not the same as a "standard path", I agree. Hopefully that's clear in my documentation. That's also something I suspect is causing many confusion, which would be a notion that a "user added search path" would be exactly the same as a "standard path", but it isn't.
cheers
Have anyone tried making a graph of such a picture? I remember seeing that on Gem and its chain
Could the path structure be extracted from the code by some utilities like http://www.gson.org/egypt/egypt.html ?
fdch.github.io/tv
On Jul 29, 2017, at 2:36 PM, Alexandre Torres Porres porres@gmail.com wrote:
may be that there's not a clear picture and consensus about Pd's fundamental structure.
2017-07-29 15:57 GMT-03:00 Fede Camara Halac camarafede@gmail.com:
Have anyone tried making a graph of such a picture?
well, I made a 14 page documentation https://drive.google.com/file/d/0B3AoiT0xk8fnYWV5anJZeXZ2MDg/view in an attempt to do so - as pointed in this other thread https://lists.puredata.info/pipermail/pd-list/2017-07/119753.html - but I don't know if I get your inquiry
Yes! And I truly appreciate your doc! I read it and will refer to it definitely!!
+1 that it should be accessible from pd's help.
I only meant to ask if there is a visual graph of the structure, and i think that it can be extracted from the code with tools for that purpose. Seeing an outline of the structure might further enhance your work and every other new user's knowledge of how pd looks and loads and calls things. It will be helpful for making externals as well!
fdch.github.io/tv
On Jul 29, 2017, at 3:09 PM, Alexandre Torres Porres porres@gmail.com wrote:
2017-07-29 15:57 GMT-03:00 Fede Camara Halac camarafede@gmail.com:
Have anyone tried making a graph of such a picture?
well, I made a 14 page documentation in an attempt to do so - as pointed in this other thread - but I don't know if I get your inquiry
Hey Alex, thanks for your great work!
personally, I'm not sure about the last paragraph on p. 9, though:
As mentioned, externals are usually installed in one of the Standard Paths. Having externals in a Relative Path is uncommon, this usually happens only when a patch is provided with abstractions in the same folder
having externals relative to a patch is not so uncommon and IMHO also good practice for self-contained projects which should work out of the box.
"User added search paths" are not the same as a "standard path", I agree. Hopefully that's clear in my documentation. That's also something I suspect is causing many confusion, which would be a notion that a "user added search path" would be exactly the same as a "standard path", but it isn't.
user added search paths are indeed a bit confusing. I think a big difference is the fact that you can't have relative paths to a user added search path via [declare]. Let's say I added the search path 'C:/Pd/libs' with a folder 'mylib' containing foo.pd. I can do [mylib/foo] but I can't do [declare -stdpath mylib] and then just [foo] because - as you said - it's not a standard path.
anyway, your guide will be really helpful for beginners!
Christof
Gesendet: Samstag, 29. Juli 2017 um 20:36 Uhr Von: "Alexandre Torres Porres" porres@gmail.com An: "Jesse Mejia" jmejia@anestheticaudio.com, "pd-list@lists.iem.at" pd-list@lists.iem.at Betreff: Re: [PD] New users and external path struggles
Thanks for your input. This is a recurring topic that me and others have pointed. I've made simple suggestions that'd take care of most of this, including one of yours, but found resistance. Now, some of the feedback, unexpectedly, led me to suspect much of the resistance comes from not actually getting the issue in the first place! Thus, an underlying issue may be that there's not a clear picture and consensus about Pd's fundamental structure. So perhaps that needs to be sorted out before aiming for improvements. To be more specific, you mention issues related to Pd's current "Standard Paths", given that it is clear to you that this is the best practice for externals. Surprisingly, that is not a consensus between developers.
Hence, I when posting my documentation in the other thread (linked here[https://lists.puredata.info/pipermail/pd-list/2017-07/119753.html]), I opened it up for discussion to see if what I had there was in fact a consensus or not. Namely, if "Standard Paths" were the canonical way of installing externals or not. So far, 5 of us agree it is and share this same view. Nonetheless, believe me, not everyone shares it. But I'm hopeful we'll sort it out one way or another. It's to the interest of all.
2017-07-29 14:35 GMT-03:00 <jmejia@anestheticaudio.com[mailto:jmejia@anestheticaudio.com]>:
I understand that users can add a path like this manually - but that's an additional hurdle - and since deken is so tightly integrated, it doesn't seem like that should be necessary. It also causes confusion when you move paths across systems.
"User added search paths" are not the same as a "standard path", I agree. Hopefully that's clear in my documentation. That's also something I suspect is causing many confusion, which would be a notion that a "user added search path" would be exactly the same as a "standard path", but it isn't. cheers_______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list%5Bhttps://lists.puredata.info/l...]
2017-07-29 18:35 GMT-03:00 Christof Ressi christof.ressi@gmx.at:
having externals relative to a patch is not so uncommon and IMHO also good practice for self-contained projects which should work out of the box.
Agreed! I really meant to say it is not common to have libraries, say "cyclone", here and there, just so it is in a relative path, you know? Guess I can develop on that so it gets clear. It's just hard to find the balance of how much objective and clear you can be, that's why feedback is important ;) so thanks
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
2017-07-29 18:42 GMT-03:00 Roman Haefeli reduzent@gmail.com:
why is unhiding necessary in the first place?
So you can easily browse it, navigate there, manage it. Like you wanna throw away an external library you found to hate or doesn't work, etc... I can only see reasons to easily access your external folders, and none to the opposite.
I don't see why you need to change permissions or view settings.
I think not for %appdata%, but "extra" folder in windows needs to change permissions. But then, I don't think extra is a good place for externals for beginners. Say you throw Pd away and get the new version... now you lost all your externals! Bad, huh?
Out of the Standard Paths, I suggest the default location is the "User Specific Path". Deken does not take care of that yet, but there's been discussions in how to improve it (which likely won't make to 0.48 around the corner).
Your experiences might stem from Pd 0.47.1 where Deken did _not_ create
any directory automatically.
This may be ambiguous, let's just be clear that this only happens now (with Pd 0.48-test6) in a very specific case. Anyway, check out IOhannes' plans for deken in the end of the discussion here https://github.com/pure-data/pure-data/pull/140 - revolutionary and amazing/exciting stuff.
I'm a proponent of automatic search path directory creation
Me too!
What we have with Deken is not quite there yet. But a middle ground is being set to get there, and create such folders at requests. I guess I'm fine with that... But... again, I suspect much os the resistance to this may come from not really grasping the whole concept and usage of "Standard Paths". And I still cannot understand arguments I've heard against it.
I know at one point the issue was not that it was annoying that the folder would be created, but that the desired folder should be another one. Anyway, you were a part of that discussion, I'll link it here https://lists.puredata.info/pipermail/pd-list/2016-06/115377.html for others to check it out.
cheers
2017-07-29 18:42 GMT-03:00 Roman Haefeli reduzent@gmail.com:
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.
Sorry, again on it... "the right place" as of now, is different for each OS, so we don't really have a "Default" considered to be "the right/best place" for most cases.
Moreover, besides the reasoning I gave that a visible folder is needed. For now, on Mac OS, if I want deken to download to the "user specific" folder, I need to do to this hidden secretive place and create the folder in the first place (no, it won't suggest it and automatically create it for me).
cheers
well, since this debate popped out, I can point to a deken issue on github here: https://github.com/pure-data/deken/issues/156 - I had opened it a few days ago, where I suggested a simple change that'd improve some of these issues.
All I ask is that deken consistently suggests "user specific" standard path at first, for all operating systems. As it already does, if the folder doesn't exist, it can create it for you. So then newbies don't need to learn "hacks" to make deken download to a reasonable option out of the box, and it'd all work.
I get this might be too late in the game for the next release round the corner, and I'm cool with that. Also, I've shown that IOhannes has big and awesome plans for deken not in the far future... but anyway, I threw it on the table ;)
cheers
2017-07-29 20:39 GMT-03:00 Alexandre Torres Porres porres@gmail.com:
2017-07-29 18:42 GMT-03:00 Roman Haefeli reduzent@gmail.com:
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.
Sorry, again on it... "the right place" as of now, is different for each OS, so we don't really have a "Default" considered to be "the right/best place" for most cases.
Moreover, besides the reasoning I gave that a visible folder is needed. For now, on Mac OS, if I want deken to download to the "user specific" folder, I need to do to this hidden secretive place and create the folder in the first place (no, it won't suggest it and automatically create it for me).
cheers
i agree that this is the biggest hurdle for newbies and as many can attest is sometimes a problem at demos/workshops with less experienced users
Thanks!
Patrick Pagano B.S, M.F.A
Assistant Professor in Residence
Digital Media & Design
Web & Interactive Technologies
University of Connecticut, Stamford
(352)-226-2016
From: Pd-list pd-list-bounces@lists.iem.at on behalf of Alexandre Torres Porres porres@gmail.com Sent: Saturday, July 29, 2017 7:55:35 PM To: pd-list@lists.iem.at Subject: Re: [PD] New users and external path struggles
well, since this debate popped out, I can point to a deken issue on github here: https://github.com/pure-data/deken/issues/156 - I had opened it a few days ago, where I suggested a simple change that'd improve some of these issues.
All I ask is that deken consistently suggests "user specific" standard path at first, for all operating systems. As it already does, if the folder doesn't exist, it can create it for you. So then newbies don't need to learn "hacks" to make deken download to a reasonable option out of the box, and it'd all work.
I get this might be too late in the game for the next release round the corner, and I'm cool with that. Also, I've shown that IOhannes has big and awesome plans for deken not in the far future... but anyway, I threw it on the table ;)
cheers
2017-07-29 20:39 GMT-03:00 Alexandre Torres Porres <porres@gmail.commailto:porres@gmail.com>: 2017-07-29 18:42 GMT-03:00 Roman Haefeli <reduzent@gmail.commailto:reduzent@gmail.com>:
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.
Sorry, again on it... "the right place" as of now, is different for each OS, so we don't really have a "Default" considered to be "the right/best place" for most cases.
Moreover, besides the reasoning I gave that a visible folder is needed. For now, on Mac OS, if I want deken to download to the "user specific" folder, I need to do to this hidden secretive place and create the folder in the first place (no, it won't suggest it and automatically create it for me).
cheers
Chiming in here as well. At least one factor instigating this current thread was me asking in the Facebook group if there is a simple, canonical way of installing GEM via deken.
Of note: every reply apart from Alexandre's told me I should install Extended, or install Purr Data, or copy the lib binaries from those into my course material, or use a live Linux distro, or use a preinstalled RasPi, or do every other crazy/complicated thing *besides* use deken. This is how the user community perceives the situation at this moment.
Disclaimer: I am aware that GEM does not run on 64 bit, and I could not use Extended because I required the [metro] object from Pd >= 0.45
I just did a one day workshop last weekend, and after giving the participants pre-flight instructions on how to install GEM that worked fine for me, 10 out of 12 could not create the GEM objects.
If it's only a 5 hour workshop and you spend more than an hour dealing with each participant's individual system to install and config while the others sit around and wait, what this tells me is that the deken system might not be ready for prime time yet.
Alexandre's document is great, but new users will not read 14 pages to install libs they have never used before. I miss Extended for this ease-of-use terribly, and I wonder how after two decades of Pd these issues still haven't been addressed completely in a systematic way which allows people to simply install and go (as Extended did once upon a time).
I guess it's important to debate whether it's "correct" to allow Pd to create directories etc etc, but the real crash test should still be whether a classroom full of undergrad art students on mixed platforms, and who don't just-so-happen-to-have a background in CompSci as well, can get things up and running without stress.
Best Sunday wishes to all. Derek
2017-07-30 7:30 GMT-03:00 Derek Holzer via Pd-list pd-list@lists.iem.at:
new users will not read 14 pages to install libs they have never used before.
My documentation won't even tell you how to deal with any issue pointed here (as going to a hidden system folder and create a standard path, etc). So it doesn't solve it all and it should work intuitively out of the box anyway.
I miss Extended for this ease-of-use terribly, and I wonder how after two
decades of Pd these issues still haven't been addressed completely in a systematic way which allows people to simply install and go (as Extended did once upon a time).
I think Extended overshadowed vanilla's issues of managing externals. After it died we did something about it, which is deken (introduced in 0.47). It's all too recent then, but we haven't made much progress since the release of 0.47-1 and that's unfortunate.
the real crash test should still be whether a classroom full of undergrad art students on mixed platforms, and who don't just-so-happen-to-have a background in CompSci as well, can get things up and running without stress.
The upcoming release improves it a little, but we're not quite there yet in my opinion. I can arguably say Pd would pass this test if at least this one idea was considered: https://github.com/pure-data/deken/issues/156 - I didn't see a real opposition to it and I also don't see this coming in the way of future enhancements. So maybe we do at least that for 0.48?
cheers
With pd-0.47 this is a simple guide how to install GEM on Windows:
- create C:/Users/You/AppData/Roaming/Pd (the user specific standard path on Windows) if it doesn't exist yet.
- open Pd -> find externals -> search for 'gem' -> download
- create a new patch and create [declare -stdlib gem -stdpath gem]. the gem library is now loaded and gem abstractions can be found in this patch all subpatches.
for OSX and Linux it's the same except for the user specific standard path (see Alex' HOWTO).
if you don't want to create a [declare] all the time, you can add "gem" to "Startup..." and the Gem folder path to "Path..."
once the folder is created, installing another library (which is not a single binary pack) is as simple as:
- search and install from deken
- [declare -stdpath libname] or add the folder path to "Path..." (the latter needs a restart of Pd).
How is that complicated? Or more complicated than:
install Extended, or install Purr Data, or copy the lib binaries from those into my course material, or use a live Linux distro, or use a preinstalled RasPi, or do every other crazy/complicated thing
Of course there can be always improvements made to deken but I think we got to a point where it's already really easy and convenient to use. I think we just have to communicate things and Alex' HOWTO is a great starting point. 14 pages (with a huge font size) is not a lot and it contains essential information every Pd user has to know.
but for a workshop situation like yours you can just use a quick guide like above.
Christof
Gesendet: Sonntag, 30. Juli 2017 um 12:30 Uhr Von: "Derek Holzer via Pd-list" pd-list@lists.iem.at An: pd-list@lists.iem.at Betreff: Re: [PD] New users and external path struggles
Chiming in here as well. At least one factor instigating this current thread was me asking in the Facebook group if there is a simple, canonical way of installing GEM via deken.
Of note: every reply apart from Alexandre's told me I should install Extended, or install Purr Data, or copy the lib binaries from those into my course material, or use a live Linux distro, or use a preinstalled RasPi, or do every other crazy/complicated thing *besides* use deken. This is how the user community perceives the situation at this moment.
Disclaimer: I am aware that GEM does not run on 64 bit, and I could not use Extended because I required the [metro] object from Pd >= 0.45
I just did a one day workshop last weekend, and after giving the participants pre-flight instructions on how to install GEM that worked fine for me, 10 out of 12 could not create the GEM objects.
If it's only a 5 hour workshop and you spend more than an hour dealing with each participant's individual system to install and config while the others sit around and wait, what this tells me is that the deken system might not be ready for prime time yet.
Alexandre's document is great, but new users will not read 14 pages to install libs they have never used before. I miss Extended for this ease-of-use terribly, and I wonder how after two decades of Pd these issues still haven't been addressed completely in a systematic way which allows people to simply install and go (as Extended did once upon a time).
I guess it's important to debate whether it's "correct" to allow Pd to create directories etc etc, but the real crash test should still be whether a classroom full of undergrad art students on mixed platforms, and who don't just-so-happen-to-have a background in CompSci as well, can get things up and running without stress.
Best Sunday wishes to all. Derek
-- derek holzer noise.art.technology http://macumbista.net
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
On 2017-07-30 08:39, Christof Ressi wrote:
With pd-0.47 this is a simple guide how to install GEM on Windows:
- create C:/Users/You/AppData/Roaming/Pd (the user specific standard path on Windows) if it doesn't exist yet.
- open Pd -> find externals -> search for 'gem' -> download
- create a new patch and create [declare -stdlib gem -stdpath gem]. the gem library is now loaded and gem abstractions can be found in this patch all subpatches.
for OSX and Linux it's the same except for the user specific standard path (see Alex' HOWTO).
if you don't want to create a [declare] all the time, you can add "gem" to "Startup..." and the Gem folder path to "Path..."
once the folder is created, installing another library (which is not a single binary pack) is as simple as:
- search and install from deken
- [declare -stdpath libname] or add the folder path to "Path..." (the latter needs a restart of Pd).
How is that complicated?
On OSX it's actually unfortunately like this - BEFORE step 1, before you can create the directory ~/Library/Pd:
If you're running Lion or Mavericks, open a terminal and type this command: /usr/bin/chflags nohidden ~/Library (you may have to do this again after apple does a system update)
If you're running El Capitan or Yosemite, follow these instructions to unhide ~/Library http://osxdaily.com/2014/12/16/show-user-library-folder-os-x-yosemite/
If you're running Sierra, follow these instructions to unhide ~/Library https://consumingtech.com/unhide-make-library-folder-visible-macos-sierra/
Again - we just need a standard path for externals that the OS considers to be userspace to resolve this.
Like ~/Documents/Pd
I'm not asking that it be auto-created (although I would personally like that too). I'm just asking that it be added to Pd's search path.
Disclaimer: I am aware that GEM does not run on 64 bit,
this is a whole new discussion we should start and after new pd release we should figure out how to go forward with this. as dan mentioned avfoundation osx framework plugin is 20% done. i have compiled a couple days ago and it DOES load a film but there is some kind of memory leak which crashes pd....
again.... we should start a separate list thread on this. maybe on gem-dev?
Working on Pd the last couple weeks has been rewarding in providing
usability improvements but, at this point, it feels like whack a mole & burn out.
5 serious gold stars and a major round of applause... im sure there is no thanking enough on the great work...
m
On Sun, Jul 30, 2017 at 6:30 AM, Derek Holzer via Pd-list < pd-list@lists.iem.at> wrote:
Chiming in here as well. At least one factor instigating this current thread was me asking in the Facebook group if there is a simple, canonical way of installing GEM via deken.
Of note: every reply apart from Alexandre's told me I should install Extended, or install Purr Data, or copy the lib binaries from those into my course material, or use a live Linux distro, or use a preinstalled RasPi, or do every other crazy/complicated thing *besides* use deken. This is how the user community perceives the situation at this moment.
Disclaimer: I am aware that GEM does not run on 64 bit, and I could not use Extended because I required the [metro] object from Pd >= 0.45
I just did a one day workshop last weekend, and after giving the participants pre-flight instructions on how to install GEM that worked fine for me, 10 out of 12 could not create the GEM objects.
If it's only a 5 hour workshop and you spend more than an hour dealing with each participant's individual system to install and config while the others sit around and wait, what this tells me is that the deken system might not be ready for prime time yet.
Alexandre's document is great, but new users will not read 14 pages to install libs they have never used before. I miss Extended for this ease-of-use terribly, and I wonder how after two decades of Pd these issues still haven't been addressed completely in a systematic way which allows people to simply install and go (as Extended did once upon a time).
I guess it's important to debate whether it's "correct" to allow Pd to create directories etc etc, but the real crash test should still be whether a classroom full of undergrad art students on mixed platforms, and who don't just-so-happen-to-have a background in CompSci as well, can get things up and running without stress.
Best Sunday wishes to all. Derek
-- derek holzer noise.art.technology http://macumbista.net
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/li stinfo/pd-list
2017-07-30 14:17 GMT-03:00 me.grimm megrimm@gmail.com:
5 serious gold stars and a major round of applause... im sure there is no thanking enough on the great work...
+1000
We love you Dan :-)
Gesendet: Sonntag, 30. Juli 2017 um 19:27 Uhr Von: "Alexandre Torres Porres" porres@gmail.com An: "me.grimm" megrimm@gmail.com Cc: "Derek Holzer" macumbista@googlemail.com, "pd-list@lists.iem.at" pd-list@lists.iem.at Betreff: Re: [PD] New users and external path struggles
2017-07-30 14:17 GMT-03:00 me.grimm megrimm@gmail.com:
5 serious gold stars and a major round of applause... im sure there is no thanking enough on the great work...
+1000 _______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
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
-
Alexandre Torres Porres -
Christof Ressi -
Derek Holzer -
Fede Camara Halac -
jmejia＠anestheticaudio.com -
me.grimm -
Pagano, Patrick -
Roman Haefeli