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

[Hans-Christoph Steiner]

On Jul 31, 2008, at 6:30 AM, Matt Barber wrote:

>> '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.


Now that there has been quite a bit of discussion, I think it's  
really time to sketch out ideas.  One good way is to make example  
patches of how things might work and post them.

.hc

-------------- next part --------------
A non-text attachment was scrubbed...
Name: namespaces.pd
Type: application/octet-stream
Size: 1798 bytes
Desc: not available
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20080801/8907bb51/attachment.obj>
-------------- next part --------------

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



------------------------------------------------------------------------ 
----

Looking at things from a more basic level, you can come up with a  
more direct solution... It may sound small in theory, but it in  
practice, it can change entire economies.     - Amy Smith