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

[Miller Puckette]

I'm not sure this really happens but... if you add startup loads to
preferences through Pd venilla, then if they don't load or crash for
Pd extended, this would be made more confusing if the libraries weren't
visible from a dialog somewhere.

On the other hand, you could fix fix Pd extended actually to
ignore "lib" preferences altogether (although respect them on the
command line for 'experts' -- then it would mke sense to get rid of
the dialog and perhaps people would be very grateful for the simplification.

cheers
Miller

On Tue, Sep 20, 2011 at 11:58:47AM -0400, Hans-Christoph Steiner 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