[PD] now that we don't have user-settable global search paths in Pd-E 0.43

[Jonathan Wilkes]

----- Original Message -----
> From: katja <katjavetter at gmail.com>
> To: pd-list <pd-list at iem.at>
> Cc: 
> Sent: Sunday, February 3, 2013 4:32 PM
> Subject: [PD] now that we don't have user-settable global search paths in Pd-E 0.43
> 

[...]

> After struggling with Pd search paths for many years, I'm finally
> starting to get a grip on it. Thanks to / forced by discontinuation of
> user-settable global paths. No matter how, I guess this will remain
> tough matter for Pd beginners.

It shouldn't be that way.

There is currently missing functionality in Pd that makes it difficult
for beginners.  For example, in the 2.control/12.PART2.subpatch.pd
the user is taught how to use Pd objects they've learned to create
abstractions...

There is a separate file in this directory named "sendnumber.pd" which is loaded _every_ time you type "sendnumber" in a box. Click on a "sendnumber" box above to see it. You can make changes in the subpatch and save them. The changes will be saved back to sendnumber.pd and not as part of this (containing) patch.

...(My emphasis)

The problem in 0.42 is that "sendnumber.pd" won't load if there
is an external foo/sendnumber, which may be loaded by
default.  The problem in 0.43 is when the user learns about
externals and wants to [import foo], foo/sendnumber will
override "sendnumber.pd".  The problem with 0.now_with_std_libs
is the same as 0.42.

But from the beginner's perspective, they put "sendnumber.pd" in
the same directory as their patch, and it loads.  End of story.  This
should be respected at the top of the hierarchy for how things get
loaded-- otherwise we're teaching beginners the wrong lesson
(and forcing them to "correct" their knowledge implicitly when what
they've learned turns out not to work in obscure cases which break
their patches, as with [pow~]).

We're also cementing a learning curve into the software that starts
with the "idea" of expressivity(through the use of abstractions)
and ends with abstractions being 2nd class citizens and coding
externalsrevealed to be the "real" way to get serious work done
in Pd.  I imagine that's one of the reasons you have a lot of
homemade binaries in your bag of tricks-- if you could get the
same functionality (and comparable efficiency) out of abstractions,
they'd solve most of your compatibility problems.

Anyway, respecting the patch's containing directory (and recursively,
its subdirs) as the primary place to load stuff will require Pd to
do patch-local loading, which it doesn't currently do.  Only then will
the beginner's lesson actually be true, and the problem with
[declare] inside abstractions will go away (because the abstraction's
directory will be its primary place to load stuff, too).  And of course
people who want to load from other locations like sys paths, etc.,
would still be able to do it, the same way they do it now.

Well, with the small caveat that starting a new patch in a random
directory (like "My Downloads") may not be a good idea, but it's
not in the first place... :)

-Jonathan

> 
> Katja
> 
> _______________________________________________
> Pd-list at iem.at mailing list
> UNSUBSCRIBE and account-management -> 
> http://lists.puredata.info/listinfo/pd-list
>