Re: [PD] New users and external path struggles

[Jonathan Wilkes via Pd-list]

>> None will clash with the others.

> that's also true for Pd vanilla!

Yes-- the class loader behavior I described is part of the 
Pd vanilla codebase.
-Jonathan   ___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] New users and external path struggles

[Christof Ressi]

> None will clash with the others.

that's also true for Pd vanilla!
 

Gesendet: Sonntag, 30. Juli 2017 um 23:58 Uhr
Von: "Jonathan Wilkes" <jancs...@yahoo.com>
An: "Christof Ressi" <christof.re...@gmx.at>, "Dan Wilcox" 
<danomat...@gmail.com>
Cc: Pd-List <pd-list@lists.iem.at>
Betreff: Re: [PD] New users and external path struggles

> yeah, this worked because of libdir.
 
A few details:
 
* The Pd extended libdir loader searches for a $LIBNAME-meta.pd file. If
it finds it it adds the directory containing it to the global search path.
* namespace prefixes (probably better referred to as directory prefixes) will
add the prefixed name to Pd's object creator methodspace.
 
So if you do this:
[foo/image]
[bar/image]
[/home/foo/decade_old_version/build/bin/image]
 
None will clash with the others.
 
(Of course if you have /home/foo AND /home/bar/foo in your search path
then you are right back to depending on path search order...)
 
-Jonathan

___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] New users and external path struggles

[Jonathan Wilkes via Pd-list]

> yeah, this worked because of libdir. 

A few details:

* The Pd extended libdir loader searches for a $LIBNAME-meta.pd file. If 
it finds it it adds the directory containing it to the global search path.* 
namespace prefixes (probably better referred to as directory prefixes) will 
add the prefixed name to Pd's object creator methodspace.
So if you do 
this:[foo/image][bar/image][/home/foo/decade_old_version/build/bin/image]
None will clash with the others.
(Of course if you have /home/foo AND /home/bar/foo in your search path 
then you are right back to depending on path search order...)
-Jonathan
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] New users and external path struggles

[Christof Ressi]

yeah, this worked because of libdir. 

Gesendet: Sonntag, 30. Juli 2017 um 22:40 Uhr
Von: "Dan Wilcox" <danomat...@gmail.com>
An: "Christof Ressi" <christof.re...@gmx.at>
Cc: "Miller Puckette" <m...@ucsd.edu>, Pd-List <pd-list@lists.iem.at>
Betreff: Re: [PD] New users and external path struggles

I guess I mean nothing by than and am completely wrong. I'm thinking of the old 
extended behavior with libdir finding things automatically. I use *very few* 
externals at this point, so I shouldn't say anything more I suppose.
 

On Jul 30, 2017, at 10:38 PM, Christof Ressi 
<christof.re...@gmx.at[mailto:christof.re...@gmx.at]> wrote: 

whereas throwing stuff in ../extra "just works".
what do you mean by that? when I throw 'mylib' folder (containing foo.pd) into 
../extra, I either have to add ../extra/mylib to the user paths OR do [declare 
-stdpath mylib] or always do [mylib/foo]. so ../extra (and other standard 
paths) are apparently *not* searched recursively when trying to load an object 
and behave the same as user paths. it's just with [declare] where the 
difference comes into play.

I'm on Windows 7. Is this different on other systems!? 


Dan Wilcox
@danomatika[http://twitter.com/danomatika]
danomatika.com[http://danomatika.com]
robotcowboy.com[http://robotcowboy.com]
 

___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] New users and external path struggles

[Alexandre Torres Porres]

2017-07-30 17:38 GMT-03:00 Christof Ressi :

> > whereas throwing stuff in ../extra "just works".
>
> what do you mean by that? when I throw 'mylib' folder (containing foo.pd)
> into ../extra, I either have to add ../extra/mylib to the user paths OR do
> [declare -stdpath mylib] or always do [mylib/foo]. so ../extra (and other
> standard paths) are apparently *not* searched recursively when trying to
> load an object and behave the same as user paths. it's just with [declare]
> where the difference comes into play.
>

Yeah... We also need to add *each* external's subdirectories in such case,
if I get what you mean... Like, if I download "cyclone" to extra and I try
[cycle~], it fails. The options are: *A)* put cyclone's subdirectory in the
path, or *B)* use [cyclone/cycle~]; *C) *use [declare -stdpath cyclone]. So
it doesn't "just works", you gotta do one of these...


> This would be why adding something like ~/Documents/Pd to st_staticpath is
> so attractive because it negates needing to add each lib to the user search
> paths.
>

If ~/Documents/Pd was added to st_staticpath, you'd gain the options B) and
C), but you'd still have to put ~/Documents/Pd/cyclone in the path, if
that's how you roll (and you don't care for B/C). So that's not what
changes.

ps. I have that new thread :)
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] New users and external path struggles

[Dan Wilcox]

I guess I mean nothing by than and am completely wrong. I'm thinking of the old 
extended behavior with libdir finding things automatically. I use *very few* 
externals at this point, so I shouldn't say anything more I suppose.

> On Jul 30, 2017, at 10:38 PM, Christof Ressi  wrote:
> 
>> whereas throwing stuff in ../extra "just works".
> 
> what do you mean by that? when I throw 'mylib' folder (containing foo.pd) 
> into ../extra, I either have to add ../extra/mylib to the user paths OR do 
> [declare -stdpath mylib] or always do [mylib/foo]. so ../extra (and other 
> standard paths) are apparently *not* searched recursively when trying to load 
> an object and behave the same as user paths. it's just with [declare] where 
> the difference comes into play.
> 
> I'm on Windows 7. Is this different on other systems!?


Dan Wilcox
@danomatika 
danomatika.com 
robotcowboy.com 



___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] New users and external path struggles

[Christof Ressi]

> whereas throwing stuff in ../extra "just works".

what do you mean by that? when I throw 'mylib' folder (containing foo.pd) into 
../extra, I either have to add ../extra/mylib to the user paths OR do [declare 
-stdpath mylib] or always do [mylib/foo]. so ../extra (and other standard 
paths) are apparently *not* searched recursively when trying to load an object 
and behave the same as user paths. it's just with [declare] where the 
difference comes into play.

I'm on Windows 7. Is this different on other systems!?

 

Gesendet: Sonntag, 30. Juli 2017 um 22:21 Uhr
Von: "Dan Wilcox" <danomat...@gmail.com>
An: "Miller Puckette" <m...@ucsd.edu>
Cc: Pd-List <pd-list@lists.iem.at>
Betreff: Re: [PD] New users and external path struggles

I think what it boils down to is that the paths in st_staticpath (Pd) are used 
recursively and the paths in sys_searchpath (user) are not. This means if we 
have an deken externals download dir, we still have to add *each* external's 
subdirectories to sys_searchpath since it's not recursive, whereas throwing 
stuff in ../extra "just works". This would be why adding something like 
~/Documents/Pd to st_staticpath is so attractive because it negates needing to 
add each lib to the user search paths.
 
Maybe we need an option to add recursive search paths?
 

On Jul 30, 2017, at 10:00 PM, 
pd-list-requ...@lists.iem.at[mailto:pd-list-requ...@lists.iem.at] wrote: 

From: Miller Puckette <m...@ucsd.edu[mailto:m...@ucsd.edu]>
Subject: Re: [PD] New users and external path struggles
Date: July 30, 2017 at 8:56:30 PM GMT+2
To: Alexandre Torres Porres <por...@gmail.com[mailto:por...@gmail.com]>
Cc: pd-list <pd-l...@iem.at[mailto:pd-l...@iem.at]>

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 


Dan Wilcox
@danomatika[http://twitter.com/danomatika]
danomatika.com[http://danomatika.com]
robotcowboy.com[http://robotcowboy.com]
 ___ Pd-list@lists.iem.at mailing 
list UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list[https://lists.puredata.info/listinfo/pd-list]

___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] New users and external path struggles

[Dan Wilcox]

I think what it boils down to is that the paths in st_staticpath (Pd) are used 
recursively and the paths in sys_searchpath (user) are not. This means if we 
have an deken externals download dir, we still have to add *each* external's 
subdirectories to sys_searchpath since it's not recursive, whereas throwing 
stuff in ../extra "just works". This would be why adding something like 
~/Documents/Pd to st_staticpath is so attractive because it negates needing to 
add each lib to the user search paths.

Maybe we need an option to add recursive search paths?

> On Jul 30, 2017, at 10:00 PM, pd-list-requ...@lists.iem.at wrote:
> 
> From: Miller Puckette <m...@ucsd.edu <mailto:m...@ucsd.edu>>
> Subject: Re: [PD] New users and external path struggles
> Date: July 30, 2017 at 8:56:30 PM GMT+2
> To: Alexandre Torres Porres <por...@gmail.com <mailto:por...@gmail.com>>
> Cc: pd-list <pd-l...@iem.at <mailto:pd-l...@iem.at>>
> 
> 
> 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


Dan Wilcox
@danomatika <http://twitter.com/danomatika>
danomatika.com <http://danomatika.com/>
robotcowboy.com <http://robotcowboy.com/>



___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] New users and external path struggles

[Alexandre Torres Porres]

yeah, I started a new thread
 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
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] New users and external path struggles

[Miller Puckette]

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.re...@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" <por...@gmail.com>
> > An: "Christof Ressi" <christof.re...@gmx.at>
> > Cc: "Jesse Mejia" <jme...@anestheticaudio.com>, pd-list <pd-l...@iem.at>
> > Betreff: Re: [PD] New users and external path struggles
> >
> >
> >
> > 2017-07-30 14:06 GMT-03:00 Christof Ressi <christof.re...@gmx.at[mailto:
> > christof.re...@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


___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] New users and external path struggles

[Christof Ressi]

> 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" <por...@gmail.com>
An: "Christof Ressi" <christof.re...@gmx.at>
Cc: "Jesse Mejia" <jme...@anestheticaudio.com>, pd-list <pd-l...@iem.at>
Betreff: Re: [PD] New users and external path struggles

 
 
2017-07-30 14:06 GMT-03:00 Christof Ressi 
<christof.re...@gmx.at[mailto:christof.re...@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

Re: [PD] New users and external path struggles

[Alexandre Torres Porres]

2017-07-30 14:06 GMT-03:00 Christof Ressi :

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

Re: [PD] New users and external path struggles

[Christof Ressi]

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: jme...@anestheticaudio.com
> An: "Christof Ressi" <christof.re...@gmx.at>
> Cc: macumbi...@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:
> > 
> > 1) create C:/Users/You/AppData/Roaming/Pd (the user specific standard path 
> > on Windows) if it doesn't exist yet.
> > 2) open Pd -> find externals -> search for 'gem' -> download
> > 3) 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:
> > 
> > 1) search and install from deken
> > 2) [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.

___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] New users and external path struggles

[Alexandre Torres Porres]

2017-07-30 12:48 GMT-03:00 Dan Wilcox :

> As I've mentioned on the super long Github discussion about this, I am
> working on a proposal to fix all of this.
>

Ok, I haven't mentioned that particular "super long Github discussion"
here. What Dan is mentioning is a Pull Request I did for exactly adding
*~/Documents/Pd* as a standard path. I wasn't gonna bring it up cause, as
mentioned, it's a big discussion, and I was afraid it'd become longer.

But since Jesse opened this thread insisting and requiring the same thing
as that Pull Request (amongst other issues), andthe github convo has been
brought up, here it is => https://github.com/pure-data/pure-data/pull/139

Maybe y'all should wait a bit and see if it solves things?
>

Dan, my last comments on github describe why I suspect it won't solve it,
as it seems you're just working on having "user added search paths" for
externals, instead of a new "Standard Path".

This thread here and a previous one on the pd list is being developed over
a consensus that a "Standard Path" is a special thing and a "user added
path" is something else. I'm not sure you're on the same page.

But we can just wait until you show us what you got.

 cheers
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] New users and external path struggles

[jmejia]

On 2017-07-30 08:39, Christof Ressi wrote:

> With pd-0.47 this is a simple guide how to install GEM on Windows:
> 
> 1) create C:/Users/You/AppData/Roaming/Pd (the user specific standard path on 
> Windows) if it doesn't exist yet.
> 2) open Pd -> find externals -> search for 'gem' -> download
> 3) 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:
> 
> 1) search and install from deken
> 2) [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.___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] New users and external path struggles

[jmejia]

On 2017-07-29 15:42, Roman Haefeli wrote:

> On Sam, 2017-07-29 at 11:35 -0600, jme...@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  ] or [declare -stdpath ].

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___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] New users and external path struggles

[Christof Ressi]

With pd-0.47 this is a simple guide how to install GEM on Windows:

1) create C:/Users/You/AppData/Roaming/Pd (the user specific standard path on 
Windows) if it doesn't exist yet.
2) open Pd -> find externals -> search for 'gem' -> download
3) 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:

1) search and install from deken
2) [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
> 

___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] New users and external path struggles

[Alexandre Torres Porres]

2017-07-30 7:30 GMT-03:00 Derek Holzer via Pd-list :

> 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
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] New users and external path struggles

[Derek Holzer via Pd-list]

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

Re: [PD] New users and external path struggles

[Pagano, Patrick]

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-boun...@lists.iem.at> on behalf of Alexandre Torres 
Porres <por...@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 
<por...@gmail.com<mailto:por...@gmail.com>>:
2017-07-29 18:42 GMT-03:00 Roman Haefeli 
<reduz...@gmail.com<mailto:reduz...@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

___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] New users and external path struggles

[Alexandre Torres Porres]

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 :

> 2017-07-29 18:42 GMT-03:00 Roman Haefeli :
>
>>
>> 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
>
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] New users and external path struggles

[Alexandre Torres Porres]

2017-07-29 18:42 GMT-03:00 Roman Haefeli :

>
> 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
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] New users and external path struggles

[Alexandre Torres Porres]

2017-07-29 18:42 GMT-03:00 Roman Haefeli :

> 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
 - 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
 for
others to check it out.

cheers
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] New users and external path struggles

[Roman Haefeli]

On Sam, 2017-07-29 at 11:35 -0600, jme...@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  ] or [declare -stdpath ]. 

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


signature.asc
Description: This is a digitally signed message part
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] New users and external path struggles

[Fede Camara Halac]

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  wrote:
> 
> 2017-07-29 15:57 GMT-03:00 Fede Camara Halac :
>> 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
>  
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] New users and external path struggles

[Alexandre Torres Porres]

2017-07-29 15:57 GMT-03:00 Fede Camara Halac :

> 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
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] New users and external path struggles

[Fede Camara Halac]

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  wrote:
> 
> may be that there's not a clear picture and consensus about Pd's fundamental 
> structure.
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
https://lists.puredata.info/listinfo/pd-list

Re: [PD] New users and external path struggles

[Alexandre Torres Porres]

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
), 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 :

> 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