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__