"36.zZw_zRtW.910.32" wrote:

hehe

...

I've got a few questions - tried to findem in the archive - no joy :(

1. is there any simple way of avoiding "multiply defined" type errors when

using arrays within an abstraction? eg. can each instance of an abstraction in a patch, have its own copy of an array named say "fred"?

or will I perhaps need to devise some tricky way of appending a unique id to the name, renaming fred "fred-id" - then letting the other objects in the abstraction know the new name of the array in case they need to access?

use it like this in an abstraction: table $1 then have your superwindow say: pd myjodelabstract blub

ah, jo, thatŽs what I wanted to ask sometime ago too...

the thing with the $1 works fine, if you donŽt mind to imagine thousands of jodeltable-names. Wini mentioned that heŽs heard of $0 returning a unique ID but none of us could get this to work so I think it was just very awful fama. Since (I guess that) each window actually does have a unique-ID, why not make it available to the public (via $0 (?)); this would make "generation" of patches much more easy (and, by the way, the number of myjodeltable, yourjodeltable, hisjodeltable, ... is definitely not infinite !)

hannes

well, just to take up this blurb again...

wouldnt it make a lot of sense to have a mechanism for naming certain objects, i.e. "send", "receive", "state",... either with a $1 as argument or an inlet. i am thinking of "real" instantiation of sub-patches...

or is something like that around anyway and i just overlooked it...

thats just what came to my mind while doing subpatches, lately...

best, gert

At 17:44 Uhr +0200 08.10.1999, 36.zZw_zRtW.910.32 wrote:

...

ah, jo, that¥s what I wanted to ask sometime ago too...

the thing with the $1 works fine, if you don¥t mind to imagine thousands of jodeltable-names. Wini mentioned that he¥s heard of $0 returning a unique ID but none of us could get this to work so I think it was just very awful fama. Since (I guess that) each window actually does have a unique-ID, why not make it available to the public (via $0 (?)); this would make "generation" of patches much more easy (and, by the way, the number of myjodeltable, yourjodeltable, hisjodeltable, ... is definitely not infinite !)

yes. anyhow, if you dont refer to tables by name but by connection its all not matter. but the same problem applies to templates. well .. there's an object in max (so ive heard) which does subpatch-generation by replacing a set of given varibale names with generated others.?

its still, how can you change a recieve's name after you ve opened a generated patch ... does it eat a 'set ..'? mumpf

:::::::::::::::::::::: http://test.at/test.at http://web.fm

EOT

ah, templates und listz. my heart is beating faster. ;)

GG->Mhmm, I have created two objects "sendlocal" and "receivelocal" in GG->ggext, which only are valid within the subpatch. GG->First I thought it´s nicer to do it that way, adding the same feature GG->to state isn't a problem, and, actually it's necessary, because the GG->state is valid in the suppatch only, anyhow. GG-> GG->Then there are arrays ... we could have arraylocal too, .....

well, with templates you can help yourself defining the toplevel template outside of the subpatches and handling the arrays in the subpatches as listitems in the toplevel template. so its easy to dynamically shrink + xpand your array collection. still it involves a lot of pointer and 'until' messing in the subpatches ..

what would be good in that whole context was a 'clone' object, operating on the ascii data of a .pd template file, on bang it creates a new file with any specially marked placeholders (fpr msg names,arrays,tables,delays,sends + ~busses etc) replaced by unique strings and returning the new filename for a pd open message.

still, there could be trouble in getting back out any of those unique names if you need it in a separte patcher, maybe a catch~ somewhere else (does it eat a 'set' command?)

but anyhow , thats all closely tied to that 'model' of having some global parts of a patch(like final audio output(dac,file,network)) and clouds (i.e. nonfixed number of) modularized and cloneable subunits (instruments,efkt.modules,etc) which appear and disappear in accordance to externl influences mapped onto them, as in a pd.based 'sound outerface' living in a networked, multi'user'(human+machine) and very dynamically changing environment, ..

GG->a better solution might really be the "$0" feature, jmax has it AFAIK.

4 tmp distractn http://barely.a.live.fm/A.1d/