OTOH, the workaround is quite easy: put the existing abstraction into a new abstraction and forward the creation arguments accordingly :-). Maybe add such an example to [clone]'s help patch? Would illustrate the behaviour quite well, I think.
Gesendet: Mittwoch, 11. Mai 2016 um 17:26 Uhr Von: "Christof Ressi" christof.ressi@gmx.at An: "IOhannes m zmoelnig" zmoelnig@iem.at Cc: "Miller Puckette" msp@ucsd.edu, pd-list@lists.iem.at Betreff: Re: [PD] [clone]'s instance number
There's also a pitfall: additional creation arguments for the cloned abstraction will start with $2. For example, in [clone 16 my-abstraction 1 5 9] '1' will be parsed as $2, '5' as $3, '9' as $4 etc. No problem, if the abstraction was written for being used with [clone], but bad when cloning existing abstractions.
I'm wondering if there could be a way to get the abstraction ID without messing up existing abstractions... Maybe have a dedicated object?
For now, I think it's important to mention the parsing of additional creation arguments in the help file.
Christof
Gesendet: Mittwoch, 11. Mai 2016 um 16:25 Uhr Von: "IOhannes m zmoelnig" zmoelnig@iem.at An: pd-list@lists.iem.at Betreff: Re: [PD] [clone]'s instance number
On 2016-05-11 16:18, Liam Goodacre wrote:
Would it be possible to access [clone]'s unique instance number from within the patch, a bit like a creation argument? This could be used to achieve differentiation between the abstractions, ie. if the abstraction contains "tabread4~ $-1.array" and the $-1 is replaced with the instance number, then each instance could read a different file. Of course there are other ways of doing this, but it would be neat to do it with clone, and I'm wondering if there's a way.
isn't this what $1 is already doing in clone's instances?
fgasdmr IOhannes
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list