[PD] some macro ideas

[Frank Barknecht]

Hallo,
padawan12 hat gesagt: // padawan12 wrote:

> "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"

If this "dumb user" wasn't so dumb to reject having to create
abstractions in a seperate file, he would be a lucky user because he
would be able to do everything he wanted to using abstractions in
seperate files.

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

I've said it before and I say it again: There's more than one file in
life. ;)

A patch with 50 subpatches should be rewritten and modularized into a
patch using 5(!) abstractions, not the other way around.

Still I agree: An easier way to find and possible save together the
abstractions used in a patch would be very handy.

> 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 surely very true, however in regard to the problem of
subpatches vs. abstractions (leaving embedded abstractions aside for
now) an additional problem is education of the user. It took me a long
time to understand the difference between subpatches and abstractions,
time like in two years or so. Some of my very old patches try to use
arguments in subpatches etc. 

The difference is a tricky thing, but it's so very important to
understand, that I'm always getting a bit nervous if the two are
brought too close together, like in "converting abstractions to
subpatches". 

Unless different uses for subpatches and abstractions aren't fully
recognized by the user, the question of saving them externally or
internally or both is secondary. (Maybe it's even better to keep
abstractions in seperate files just to let them be "different enough"
from subpatches but I admit that's an arrogant view.)

Ciao
-- 
 Frank Barknecht                 _ ______footils.org_ __goto10.org__