[PD] [PD-dev] removing path and libs from Pd-extended preferences GUI

[Charles Henry]

Sorry-I'm a bit confused as to the difference between libs and paths,
at the moment.

Here's a situation where I like to have the path dialog:
I download an archive of abstractions (like RJDJ), and I'd like to be
able to put them anywhere, so if there's a couple different versions,
I can just tell them apart from folders.

With the path dialog, I can just right away see what set of
abstractions are on the path, change it, apply, and get to work.

How would I accomplish the same thing without it?

Chuck

On Tue, Sep 20, 2011 at 10:58 AM, Hans-Christoph Steiner <hans at at.or.at> wrote:
>
> Please give an example of how this would make this more confusing. My
> experience is the exact opposite and it is exactly this problem that
> leads me to want to remove those preferences.  The are a big source of
> confusion and problems, and most Pd-extended users do not use them.  I
> am not proposing removing them from Pd-vanilla, only Pd-extended.  I
> think globally loading libraries is a broken idea.
>
> If you remember in the days before Pd-extended, patches that relied on
> external libraries were mostly unsharable.  It could take a long time to
> track down all the dependencies, etc. and you couldn't be sure which
> [wrap], [split], [prepend], [scale], etc. the patch needed.  Having the
> configuration in the patch means at worst you know what you need to get
> it running.
>
> At this point I've taught Pd to 10 year olds, high school kids, college
> kids, masters students, and all sorts of people in workshops, college
> courses, and patching circles.  I also answer a lot of questions on
> email, on forums, and on IRC.  It is from this experience that I am
> coming from on this issue.  I have no desire to control people, I do
> have a strong desire to make Pd-extended very user friendly to newbies
> and a excellent editing experience for advanced users.
>
> And those that like the Pd-vanilla way are welcome to use it,
> Pd-extended will remain compatible with patches from Pd-vanilla as long
> as I work on it.  Of course, it is not possible to maintain 100%
> compatibility when going from Pd-extended to Pd-vanilla since extended
> includes many more objects.  There is also pd-l2ork, desiredata, etc.
> for those who want different approaches.
>
> .hc
>
> On Tue, 2011-09-20 at 13:02 +0100, Andy Farnell wrote:
>>
>> Whenever I see the words "this would _make_ people"...
>> alarm bells start ringing for me.
>>
>> Yes, the proposed behaviour is perfectly correct, logical,
>> and consistent. And utterly the wrong thing to do IMHO.
>>
>> It would frighten off newcomers and disorientate students.
>>
>> It's why we create the cushion of fairy stories
>> for kids, to soften the harsh realities of the
>> _actual_ world. Later on you learn that there isn't
>> a magic library fairy that loads everything, but it
>> helps you cope with the first steps.
>>
>> If anybody made PD that broken out of the box it
>> would require lots of work to fix in order to make
>> it fit to teach with again.
>>
>>
>>
>> > On 2011-09-19 19:32, Hans-Christoph Steiner wrote:
>> > >
>> > > Hey Miller,
>> > >
>> > > I actually think this would make switching between vanilla and extended
>> > > easier because it would make people use [import] or [declare] to load
>> > > libs, then when using vanilla, you'll know which libraries the patch
>> > > needs.  Can you think of examples where it would make things more
>> > > difficult?
>>
>
>
>
> _______________________________________________
> Pd-dev mailing list
> Pd-dev at iem.at
> http://lists.puredata.info/listinfo/pd-dev
>