Haha, oh gosh, osx really loves to hide things from their users. But yeah, documents/pd could be added to the standard paths. This would make things much easier. Processing also does that (for a reason). In the end, the user can decide where they want to put their stuff. there have been long discussions already but since it is brought up over and over again means we haven't come to a conclusion yet.
So are there arguments against documents/pd as a standard search path? Let's stay clear from the autocreation topic for now.
Gesendet: Sonntag, 30. Juli 2017 um 17:39 Uhr Von: jmejia@anestheticaudio.com An: "Christof Ressi" christof.ressi@gmx.at Cc: macumbista@googlemail.com, pd-list@lists.iem.at Betreff: Re: [PD] New users and external path struggles
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.
2017-07-30 14:06 GMT-03:00 Christof Ressi christof.ressi@gmx.at:
So are there arguments against documents/pd as a standard search path? Let's stay clear from the autocreation topic for now.
The arguments seem to be based on a view against a consensus we seem to have here, in which a standard search path is not a place for externals, and that it'd be the same as a "user added path". You can check the github discussion and see what you make of it.
Anyway, I tried pointing it out in my first response to this thread, when I said: "*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. (...) "**User added search paths" are not the same as a "standard path", I agree (...) 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.*
on a view against a consensus we seem to have here, in which a standard search path is not a place for externals,
but that's rather absurd. what is the use of a standard path if not a place where to put libraries? you described it beautifully in your HOWTO:
application specific standard path = only for this Pd installation user specific standard path = only for Pd installations of this user global standard path = for all Pd installations
who actually disagrees with this?
user defined search paths are a nice feature but they have a serious disadvantage: you can't interface them with [declare], so it's not the best thing to use with libraries. I think this is important to remember! maybe this could be resolved by adding another flag to [declare] for user defined paths, like [declare -user myfolder]. this would be a very cool feature anyway!
I think for experienced users the situation is fine. I'm really happy with Deken on Windows right now. The problem is rather that the standard search paths are awkward for beginners on Windows and OSX. They are either hidden or users don't have writing permission.
personally I really think that the user specific standard path should be autocreated (by the installer and/or Deken) - like any other program does. when I install REAPER on Windows I automatically get a folder C:\Users\Christof\AppData\Roaming\REAPER
but I also like Alex' idea that Deken should always initially propose the user specific standard path and create it when you want to install there!
sorry for being redundand but I think we have to find a consensus on this sooner or later, not necessarily for this release!
Christof
Gesendet: Sonntag, 30. Juli 2017 um 19:27 Uhr Von: "Alexandre Torres Porres" porres@gmail.com An: "Christof Ressi" christof.ressi@gmx.at Cc: "Jesse Mejia" jmejia@anestheticaudio.com, pd-list pd-list@iem.at Betreff: Re: [PD] New users and external path struggles
2017-07-30 14:06 GMT-03:00 Christof Ressi <christof.ressi@gmx.at[mailto:christof.ressi@gmx.at]>: So are there arguments against documents/pd as a standard search path? Let's stay clear from the autocreation topic for now. The arguments seem to be based on a view against a consensus we seem to have here, in which a standard search path is not a place for externals, and that it'd be the same as a "user added path". You can check the github discussion and see what you make of it. Anyway, I tried pointing it out in my first response to this thread, when I said: "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. (...) "User added search paths" are not the same as a "standard path", I agree (...) 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.
once again, check that github discussion https://github.com/pure-data/pure-data/pull/139 and see what you make of it...
2017-07-30 15:33 GMT-03:00 Christof Ressi christof.ressi@gmx.at:
on a view against a consensus we seem to have here, in which a standard
search path is not a place for externals,
but that's rather absurd. what is the use of a standard path if not a place where to put libraries? you described it beautifully in your HOWTO:
application specific standard path = only for this Pd installation user specific standard path = only for Pd installations of this user global standard path = for all Pd installations
who actually disagrees with this?
user defined search paths are a nice feature but they have a serious disadvantage: you can't interface them with [declare], so it's not the best thing to use with libraries. I think this is important to remember! maybe this could be resolved by adding another flag to [declare] for user defined paths, like [declare -user myfolder]. this would be a very cool feature anyway!
I think for experienced users the situation is fine. I'm really happy with Deken on Windows right now. The problem is rather that the standard search paths are awkward for beginners on Windows and OSX. They are either hidden or users don't have writing permission.
personally I really think that the user specific standard path should be autocreated (by the installer and/or Deken) - like any other program does. when I install REAPER on Windows I automatically get a folder C:\Users\Christof\AppData\Roaming\REAPER
but I also like Alex' idea that Deken should always initially propose the user specific standard path and create it when you want to install there!
sorry for being redundand but I think we have to find a consensus on this sooner or later, not necessarily for this release!
Christof
Gesendet: Sonntag, 30. Juli 2017 um 19:27 Uhr Von: "Alexandre Torres Porres" porres@gmail.com An: "Christof Ressi" christof.ressi@gmx.at Cc: "Jesse Mejia" jmejia@anestheticaudio.com, pd-list pd-list@iem.at Betreff: Re: [PD] New users and external path struggles
2017-07-30 14:06 GMT-03:00 Christof Ressi <christof.ressi@gmx.at[mailto: christof.ressi@gmx.at]>: So are there arguments against documents/pd as a standard search path? Let's stay clear from the autocreation topic for now.
The arguments seem to be based on a view against a consensus we seem to have here, in which a standard search path is not a place for externals, and that it'd be the same as a "user added path". You can check the github discussion and see what you make of it.
Anyway, I tried pointing it out in my first response to this thread, when I said: "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. (...) "User added search paths" are not the same as a "standard path", I agree (...) 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.
Except perhaps in this thread I can try to explain... I always meant "standard path" to refer to "stuff distributed with Pd", and "Path" to be adjustible to point to libraries that are not part of the Pd distribution. I think part of the confusion comes from different possible interpretations of "standard path" (which, as I now realize, is badly named). But I think the way forward is to somehow get the "path" mechanism to do what people are asking for.
cheers Miller
On Sun, Jul 30, 2017 at 03:46:38PM -0300, Alexandre Torres Porres wrote:
once again, check that github discussion https://github.com/pure-data/pure-data/pull/139 and see what you make of it...
2017-07-30 15:33 GMT-03:00 Christof Ressi christof.ressi@gmx.at:
on a view against a consensus we seem to have here, in which a standard
search path is not a place for externals,
but that's rather absurd. what is the use of a standard path if not a place where to put libraries? you described it beautifully in your HOWTO:
application specific standard path = only for this Pd installation user specific standard path = only for Pd installations of this user global standard path = for all Pd installations
who actually disagrees with this?
user defined search paths are a nice feature but they have a serious disadvantage: you can't interface them with [declare], so it's not the best thing to use with libraries. I think this is important to remember! maybe this could be resolved by adding another flag to [declare] for user defined paths, like [declare -user myfolder]. this would be a very cool feature anyway!
I think for experienced users the situation is fine. I'm really happy with Deken on Windows right now. The problem is rather that the standard search paths are awkward for beginners on Windows and OSX. They are either hidden or users don't have writing permission.
personally I really think that the user specific standard path should be autocreated (by the installer and/or Deken) - like any other program does. when I install REAPER on Windows I automatically get a folder C:\Users\Christof\AppData\Roaming\REAPER
but I also like Alex' idea that Deken should always initially propose the user specific standard path and create it when you want to install there!
sorry for being redundand but I think we have to find a consensus on this sooner or later, not necessarily for this release!
Christof
Gesendet: Sonntag, 30. Juli 2017 um 19:27 Uhr Von: "Alexandre Torres Porres" porres@gmail.com An: "Christof Ressi" christof.ressi@gmx.at Cc: "Jesse Mejia" jmejia@anestheticaudio.com, pd-list pd-list@iem.at Betreff: Re: [PD] New users and external path struggles
2017-07-30 14:06 GMT-03:00 Christof Ressi <christof.ressi@gmx.at[mailto: christof.ressi@gmx.at]>: So are there arguments against documents/pd as a standard search path? Let's stay clear from the autocreation topic for now.
The arguments seem to be based on a view against a consensus we seem to have here, in which a standard search path is not a place for externals, and that it'd be the same as a "user added path". You can check the github discussion and see what you make of it.
Anyway, I tried pointing it out in my first response to this thread, when I said: "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. (...) "User added search paths" are not the same as a "standard path", I agree (...) 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.
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Hi, thanks for explaining!
"standard path" to refer to "stuff distributed with Pd"
that would make sense if 'extra' would be the only stdpath. but there's also C:/Users/Christof/AppData/Roaming/Pd etc. and these are usually used for application user data. also, we came to get used to [declare -stdpath folder] resp. [declare -stdlib folder] to load/access a library which is being used for several projects VS [declare -path folder] resp. [declare -path folder] for a library which is local to a specific project.
this way it always seemed natural that we put our libaries into stdpaths, so we can load them selectively with [declare].
also, in pd-0.48.0test6 only folders in the standard paths show up in the "Libraries" section in the help browser.
the way forward is to somehow get the "path" mechanism to do what people are asking for.
I think so too! this implies that [declare] has to work with user paths. the question is how: including user paths in -stdpath? or introducing a new flag?
once this works, the user only has to create a folder somewhere in his system, ask deken to download there and load libraries with [declare]. "Startup..." already looks for libraries in the user paths, so that's fine already.
Christof
Gesendet: Sonntag, 30. Juli 2017 um 20:56 Uhr Von: "Miller Puckette" msp@ucsd.edu An: "Alexandre Torres Porres" porres@gmail.com Cc: "Christof Ressi" christof.ressi@gmx.at, pd-list pd-list@iem.at Betreff: Re: [PD] New users and external path struggles
Except perhaps in this thread I can try to explain... I always meant "standard path" to refer to "stuff distributed with Pd", and "Path" to be adjustible to point to libraries that are not part of the Pd distribution. I think part of the confusion comes from different possible interpretations of "standard path" (which, as I now realize, is badly named). But I think the way forward is to somehow get the "path" mechanism to do what people are asking for.
cheers Miller
On Sun, Jul 30, 2017 at 03:46:38PM -0300, Alexandre Torres Porres wrote:
once again, check that github discussion https://github.com/pure-data/pure-data/pull/139 and see what you make of it...
2017-07-30 15:33 GMT-03:00 Christof Ressi christof.ressi@gmx.at:
on a view against a consensus we seem to have here, in which a standard
search path is not a place for externals,
but that's rather absurd. what is the use of a standard path if not a place where to put libraries? you described it beautifully in your HOWTO:
application specific standard path = only for this Pd installation user specific standard path = only for Pd installations of this user global standard path = for all Pd installations
who actually disagrees with this?
user defined search paths are a nice feature but they have a serious disadvantage: you can't interface them with [declare], so it's not the best thing to use with libraries. I think this is important to remember! maybe this could be resolved by adding another flag to [declare] for user defined paths, like [declare -user myfolder]. this would be a very cool feature anyway!
I think for experienced users the situation is fine. I'm really happy with Deken on Windows right now. The problem is rather that the standard search paths are awkward for beginners on Windows and OSX. They are either hidden or users don't have writing permission.
personally I really think that the user specific standard path should be autocreated (by the installer and/or Deken) - like any other program does. when I install REAPER on Windows I automatically get a folder C:\Users\Christof\AppData\Roaming\REAPER
but I also like Alex' idea that Deken should always initially propose the user specific standard path and create it when you want to install there!
sorry for being redundand but I think we have to find a consensus on this sooner or later, not necessarily for this release!
Christof
Gesendet: Sonntag, 30. Juli 2017 um 19:27 Uhr Von: "Alexandre Torres Porres" porres@gmail.com An: "Christof Ressi" christof.ressi@gmx.at Cc: "Jesse Mejia" jmejia@anestheticaudio.com, pd-list pd-list@iem.at Betreff: Re: [PD] New users and external path struggles
2017-07-30 14:06 GMT-03:00 Christof Ressi <christof.ressi@gmx.at[mailto: christof.ressi@gmx.at]>: So are there arguments against documents/pd as a standard search path? Let's stay clear from the autocreation topic for now.
The arguments seem to be based on a view against a consensus we seem to have here, in which a standard search path is not a place for externals, and that it'd be the same as a "user added path". You can check the github discussion and see what you make of it.
Anyway, I tried pointing it out in my first response to this thread, when I said: "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. (...) "User added search paths" are not the same as a "standard path", I agree (...) 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.
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
yeah, I started a new thread https://lists.puredata.info/pipermail/pd-list/2017-07/119840.html and brought this up. Shall we move it there? Seems like a good idea now that we have a new focus to start over.
cheers
-
Alexandre Torres Porres -
Christof Ressi -
Miller Puckette