Hi everyone.
If i have an abstraction with an array in it, is there any way for the data to be saved in any parent patch which instantiates the abstraction, rather than in the abstraction itself? in my main patch i want lots of copies of the abstraction each with different data.
Thanks for any help.
Hallo, Peter Worth hat gesagt: // Peter Worth wrote:
If i have an abstraction with an array in it, is there any way for the data to be saved in any parent patch which instantiates the abstraction, rather than in the abstraction itself? in my main patch i want lots of copies of the abstraction each with different data.
What I would do is to move the array out of the abstraction into the parent and pass its name as abstraction argument. Example:
This is in abstract.pd:
[tabread $1]
and in parent.pd you pass the array name into $1:
[table t1] [abstract t1]
[table t2] [abstract t2]
[table t3] [abstract t3]
[table t4] [abstract t4]
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
On 4/27/07, Frank Barknecht fbar@footils.org wrote:
What I would do is to move the array out of the abstraction into the parent and pass its name as abstraction argument. Example:
This is in abstract.pd:
[tabread $1]
and in parent.pd you pass the array name into $1:
[table t1] [abstract t1]
[table t2] [abstract t2]
[table t3] [abstract t3]
[table t4] [abstract t4]
i did consider that actually, but then thought that it would make the abstraction less of a "black box" because the parent needs to know something about it's inner workings (that it requires an array).
its good to know that that's the only way though, so that i'm doing it because i have to, not because there is something about pd i dont know (if you see what i mean...)
thanks, pete.
Hallo, Peter Worth hat gesagt: // Peter Worth wrote:
i did consider that actually, but then thought that it would make the abstraction less of a "black box" because the parent needs to know something about it's inner workings (that it requires an array).
If you want to save something (the array) with the parent patch, then that something has to be in the parent, not in the abstraction itself, because if you save the abstraction, you can only save one array with the abstraction.
However if you don't need to save the abstraction and still want to have different arrays inside, you leave the array in the abstraction, but call it something with $0 like [table $0-inside] and set the values on demand from the parent.
Attached is an example on what I mean.
A third possibility would be to use some kind of state-saving system, though I wouldn't save larger tables with that. Larger tables are better served with their own files, possibly in wav-format.
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
thanks for that. by state-saving do you mean saving in a different file other than the .pd file?
On 4/28/07, Frank Barknecht fbar@footils.org wrote:
Hallo, Peter Worth hat gesagt: // Peter Worth wrote:
i did consider that actually, but then thought that it would make the abstraction less of a "black box" because the parent needs to know something about it's inner workings (that it requires an array).
If you want to save something (the array) with the parent patch, then that something has to be in the parent, not in the abstraction itself, because if you save the abstraction, you can only save one array with the abstraction.
However if you don't need to save the abstraction and still want to have different arrays inside, you leave the array in the abstraction, but call it something with $0 like [table $0-inside] and set the values on demand from the parent.
Attached is an example on what I mean.
A third possibility would be to use some kind of state-saving system, though I wouldn't save larger tables with that. Larger tables are better served with their own files, possibly in wav-format.
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
-
Frank Barknecht -
Peter Worth