[PD] declare [was: Re: Idiomatic Pd]

[Matt Barber]

> 'relative to file location' is old school pd style, easy to understand
> and together with the concept of inheritance, it covers every use case i
> can think of (which implies that i would try to adapt the way i code to
> pd and not vice versa).
>


I'd almost agree with you as long as inheritance were a strong part of
the model.

But...

Say I'm teaching a computer music course, and I've created a big
library of commented and documented abstractions to do all kinds of
neat things.  I've written a script to copy the files from some global
location to the user's current directory, all of them put into a
directory called ./cm101-abs/   This directory is further subdivided
by abstraction function: cm101-abs/control/   cm101-abs/noise/
cm101-abs/math/   etc.  In order to use them the students need to
either alter their search path or put in a rather lengthy [declare]
which might be beyond the scope of the first semester, or as part of
the script I can give them a blank file with just the [declare]
statement, which they can edit as they like.

But, if Pd had a simple flag which allowed an abstraction instance to
export a [declare] path to its parent, using names relative to the
parent, then I can make an abstraction with just the [declare] from
above, but instead of -path I use some other flag.  Then all the
students have to do is include an instance of that abstraction in
their patches and they have access to the larger suite of
abstractions.  I think of this roughly as something like including a
header (providing access to the interface of objects defined
elsewhere).  This is much simpler for the students and the teacher,
and as a bonus the students learn something similar to the "include"
concept.

Now, let's say I have a fairly complex dynamically patched
impulse-response convolution patch called [IRconv~] using [rfft~]'s
all over the place, and it has a specialized abstraction called
[fft-conv~] that's loaded dynamically into the patch which has
arguments specifying the $0 of the parent abstraction, the block size,
its associated delay (minus block delay), the name of a [table] in the
abstraction to which is written a specified set of samples from the
impulse response, the name of a [send~] to [receive~] the incoming
sound from, and the name of a [catch~] to [throw~] to.  Such a
"helper" abstraction is useless in any other context, so I want to
keep my students from using it on its own, because it might even be
detrimental and confusing to try.  I can tell them "don't use this."
Or I can stick it in a subdirectory of the directory containing
[IRconv~].pd, which is not now included in the main patch's path -- so
then ideally I [declare] that path in [IRconv~] relative to
[IRconv~].pd, and it should work without passing this path to the
space of [IRconv~]'s parent -- this is what you advocate if I
understand correctly.  But, this doesn't keep a smart student from
declaring the same path in the toplevel... so then I counter by
changing the [declare]ation of the path to [fft-conv~] in [IRconv~]
from public to private, and then it throws an error when she tries to
declare that path in the parent and load [IRconv~] at the same time.


Both things can be worked around, but I think the former would be
especially useful.  The public/private thing isn't essential, but I
think it's pedagogically more sound than not having the option.  You
might also want to allow abstractions not to accept their pathy
inheritance, especially for resources.

Matt