[PD] some macro ideas

[padawan12]

On Tue, 3 Oct 2006 19:51:57 -0400 (EDT)
Mathieu Bouchard <matju at artengine.ca> wrote:

> On Wed, 4 Oct 2006, padawan12 wrote:
> 
> > Which is why the idea of an "alias" isn't quite the same thing as an 
> > "embeded abstraction". I guess a better way of explaining what I mean is 
> > that an alias is a subpatch with local scope, so you can define $0- type 
> > things inside it like tables and then copy it with impunity, but if you 
> > edit the "master" copy the others all follow suit.
> 
> Really? Then what do you mean by "embedded abstraction" now?

[user-rant]

Really. The same as I meant by it before. I mean it literally, an abstraction
that has been embedded. I'm not being flippant, I'm talking about the 
process/action of doing just that from a users POV without caring about how
it's implemented. That's a really useful point of view if you care to take
heed of it.

When I did HCI studies in the past the most valued subjects
were the "semi-naive" users, the ones who didn't have assumptions or a priori
ideas about how things were implemented but were able to articulate their
problems and needs from an "outside" perspective. The problem with being
amongst the trees of development is you stop seeing the wood, which is not
a fault, it's just the way our minds work. I hope the OP will chip in with
some elaboration on his/her initial suggestions, but from my own position I've
definitely reached that annoying (to everybody else) point where I've now
used Pd enough to know about its limitations and things I'd like to improve
but not enough of the workings to change them. Nomenclature is already pretty
poor in Pd so it's foolish to get into semantic tangles about what words "mean"
when they speak for themselves.

Let's nail the discussion back down to Earth and address the points
of the OP. The best way to tackle this imho is to stop stroking our beards
over coding theory and examine some actual problem examples so we are clear
about the reasons.

Here is one...

"I wish to construct a piano instrument that contains a couple of
arrays and delays, and I want to be able to make copies of that instrument
inside my patch, as easily as CTL-C/CTL-V, without having to rename
tables and delays, and without having to create abstractions in a
separate file. Now, being a dumb user I just realised I made a mistake in
my instrument so I want to make one edit and have all the copies change"

Neither abstractions nor subpatches alone satisfy this.

Here's another....

"I just finished my grand oeuvre symphonie de puredata containing
50 abstractions strewn across my filesystem. I wish to place it
on my website as a simple, single file, without having to track
down each abstraction and put it into a zip file. I want to simply
load the patch, press "convert abstractions to fixed" (or something)
and save out my new "embedded" file."

The only way to do this afaik is to tediously copy and paste each 
abstraction into a subpatch and fix its $ values by hand.

and finally...

"I'm still waiting for my pony."

These are a typical beginners problems to be taken on face value. One mustn't
deconstruct the request (however stupid or impossible it may seem as a developer)
and ask "Why would you want to do that?", I just do... that's the way *users*
think. Nor must you provide an alternative method involving some obscure or
advanced facet of the language and none of the elements of the original problem,
or say "No, what you really meant was...", that's sidestepping and potentially
insulting to a user who may be an expert in their field.
That's the "listening discipline" that sets software developers apart from
mere gifted programmers. To quote the cliche - A PhD in thermodynamics of the
internal combustion engine doesn't mean you know where I want to drive to, or
even that you could drive there yourself.
 
[/user-rant]

:)

respectfully,

a.