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

[Hans-Christoph Steiner]

On 02/03/2013 06:10 PM, Jonathan Wilkes wrote:
> 
> 
> 
> 
> ----- 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... :)

Hey Katja,

Thanks for the feedback, I'm glad that, even though it was a struggle, it was
worthwhile.

While full canvas-local namespaces are a feature Pd should have, we can
improve this situation quite a bit and solve other problems by switching the
search order when loading objects.  If it searches for all types in the
current path first, then what Jonathan describes would no longer be a problem.
 Here's the proposal:

http://puredata.info/dev/PdSearchPath

.hc