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.
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
However, I was also asked that - so I think I should add something to the example to show it :)
M
On Wed, May 11, 2016 at 04:25:16PM +0200, IOhannes m zmoelnig wrote:
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
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
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
I gave this some thought but couldn't come up with anything more natural than the "$1" idea. It allows for changing the other arguments more easily than it would have been if the instance number were passed last. Also, somehow it felt more natural to have the instance number first.
If there's interest in the idea, I could add arrguments to change the behavior (such as putting $1 last instead of first)... Offhand I doubt that would get used much though.
cheers Miller
On Wed, May 11, 2016 at 05:26:21PM +0200, Christof Ressi wrote:
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
What about having an if statement that detects clone object and if so, compensates for $2 discrepancy and assigns $1 to it instead and increments from there? This way the discrepancy is internalized as opposed to something user needs to deal with.
I agree that $1 is most natural!
However, what about adding an additional flag -foo for [clone], which changes the way creation arguments are parsed? Passing -foo could ignore the object ID and rather forward creation arguments just as they are.
This wouldn't break the current behaviour of [clone], but provide some functionality to deal with ordinary abstractions more conveniently.
Christof
Gesendet: Mittwoch, 11. Mai 2016 um 18:06 Uhr Von: "Ivica Bukvic" ico@vt.edu An: "Miller Puckette" msp@ucsd.edu Cc: "IOhannes m zmoelnig" zmoelnig@iem.at, Pd-list pd-list@lists.iem.at, "Christof Ressi" christof.ressi@gmx.at Betreff: Re: [PD] [clone]'s instance number What about having an if statement that detects clone object and if so, compensates for $2 discrepancy and assigns $1 to it instead and increments from there? This way the discrepancy is internalized as opposed to something user needs to deal with. -- Ivica Ico Bukvic, D.M.A. Associate Professor Computer Music ICAT Senior Fellow Director -- DISIS, L2Ork Virginia Tech School of Performing Arts – 0141 Blacksburg, VA 24061 (540) 231-6139 ico@vt.edu www.performingarts.vt.edu[http://www.performingarts.vt.edu] disis.icat.vt.edu[http://disis.icat.vt.edu] l2ork.icat.vt.edu[http://l2ork.icat.vt.edu] ico.bukvic.net[http://ico.bukvic.net]
On May 11, 2016 11:50, "Miller Puckette" <msp@ucsd.edu[msp@ucsd.edu]> wrote:I gave this some thought but couldn't come up with anything more natural than the "$1" idea. It allows for changing the other arguments more easily than it would have been if the instance number were passed last. Also, somehow it felt more natural to have the instance number first.
If there's interest in the idea, I could add arrguments to change the behavior (such as putting $1 last instead of first)... Offhand I doubt that would get used much though.
cheers Miller
On Wed, May 11, 2016 at 05:26:21PM +0200, Christof Ressi wrote:
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[zmoelnig@iem.at]> An: pd-list@lists.iem.at[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[Pd-list@lists.iem.at] mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list%5Bhttps://lists.puredata.info/l...]
Pd-list@lists.iem.at[Pd-list@lists.iem.at] mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list%5Bhttps://lists.puredata.info/l...]
Pd-list@lists.iem.at[Pd-list@lists.iem.at] mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list%5Bhttps://lists.puredata.info/l...]
Well,
What would happen if instead of calling clone like:
[clone 16 my-abstraction 1 5 9]
we called it with:
[clone my-abstraction 16 1 5 9]
and then $1 seems quite appropriate.
?
J
On May 11, 2016, at 12:17 PM, Christof Ressi christof.ressi@gmx.at wrote:
I agree that $1 is most natural!
However, what about adding an additional flag -foo for [clone], which changes the way creation arguments are parsed? Passing -foo could ignore the object ID and rather forward creation arguments just as they are.
This wouldn't break the current behaviour of [clone], but provide some functionality to deal with ordinary abstractions more conveniently.
Christof
Gesendet: Mittwoch, 11. Mai 2016 um 18:06 Uhr Von: "Ivica Bukvic" ico@vt.edu An: "Miller Puckette" msp@ucsd.edu Cc: "IOhannes m zmoelnig" zmoelnig@iem.at, Pd-list pd-list@lists.iem.at, "Christof Ressi" christof.ressi@gmx.at Betreff: Re: [PD] [clone]'s instance number What about having an if statement that detects clone object and if so, compensates for $2 discrepancy and assigns $1 to it instead and increments from there? This way the discrepancy is internalized as opposed to something user needs to deal with. -- Ivica Ico Bukvic, D.M.A. Associate Professor Computer Music ICAT Senior Fellow Director -- DISIS, L2Ork Virginia Tech School of Performing Arts – 0141 Blacksburg, VA 24061 (540) 231-6139 ico@vt.edu www.performingarts.vt.edu[http://www.performingarts.vt.edu] disis.icat.vt.edu[http://disis.icat.vt.edu] l2ork.icat.vt.edu[http://l2ork.icat.vt.edu] ico.bukvic.net[http://ico.bukvic.net]
On May 11, 2016 11:50, "Miller Puckette" <msp@ucsd.edu[msp@ucsd.edu]> wrote:I gave this some thought but couldn't come up with anything more natural than the "$1" idea. It allows for changing the other arguments more easily than it would have been if the instance number were passed last. Also, somehow it felt more natural to have the instance number first.
If there's interest in the idea, I could add arrguments to change the behavior (such as putting $1 last instead of first)... Offhand I doubt that would get used much though.
cheers Miller
On Wed, May 11, 2016 at 05:26:21PM +0200, Christof Ressi wrote:
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[zmoelnig@iem.at]> An: pd-list@lists.iem.at[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[Pd-list@lists.iem.at] mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list%5Bhttps://lists.puredata.info/l...]
Pd-list@lists.iem.at[Pd-list@lists.iem.at] mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list%5Bhttps://lists.puredata.info/l...]
Pd-list@lists.iem.at[Pd-list@lists.iem.at] mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list%5Bhttps://lists.puredata.info/l...]
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Cool, taking this suggestion. At least for now it will work either way, but it's much more readable with the abstraction name first so I changed the help file to invoke it that way.
cheers Miller
On Wed, May 11, 2016 at 01:13:37PM -0400, Jaime Oliver wrote:
Well,
What would happen if instead of calling clone like:
[clone 16 my-abstraction 1 5 9]
we called it with:
[clone my-abstraction 16 1 5 9]
and then $1 seems quite appropriate.
?
J
On May 11, 2016, at 12:17 PM, Christof Ressi christof.ressi@gmx.at wrote:
I agree that $1 is most natural!
However, what about adding an additional flag -foo for [clone], which changes the way creation arguments are parsed? Passing -foo could ignore the object ID and rather forward creation arguments just as they are.
This wouldn't break the current behaviour of [clone], but provide some functionality to deal with ordinary abstractions more conveniently.
Christof
Gesendet: Mittwoch, 11. Mai 2016 um 18:06 Uhr Von: "Ivica Bukvic" ico@vt.edu An: "Miller Puckette" msp@ucsd.edu Cc: "IOhannes m zmoelnig" zmoelnig@iem.at, Pd-list pd-list@lists.iem.at, "Christof Ressi" christof.ressi@gmx.at Betreff: Re: [PD] [clone]'s instance number What about having an if statement that detects clone object and if so, compensates for $2 discrepancy and assigns $1 to it instead and increments from there? This way the discrepancy is internalized as opposed to something user needs to deal with. -- Ivica Ico Bukvic, D.M.A. Associate Professor Computer Music ICAT Senior Fellow Director -- DISIS, L2Ork Virginia Tech School of Performing Arts – 0141 Blacksburg, VA 24061 (540) 231-6139 ico@vt.edu www.performingarts.vt.edu[http://www.performingarts.vt.edu] disis.icat.vt.edu[http://disis.icat.vt.edu] l2ork.icat.vt.edu[http://l2ork.icat.vt.edu] ico.bukvic.net[http://ico.bukvic.net]
On May 11, 2016 11:50, "Miller Puckette" <msp@ucsd.edu[msp@ucsd.edu]> wrote:I gave this some thought but couldn't come up with anything more natural than the "$1" idea. It allows for changing the other arguments more easily than it would have been if the instance number were passed last. Also, somehow it felt more natural to have the instance number first.
If there's interest in the idea, I could add arrguments to change the behavior (such as putting $1 last instead of first)... Offhand I doubt that would get used much though.
cheers Miller
On Wed, May 11, 2016 at 05:26:21PM +0200, Christof Ressi wrote:
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[zmoelnig@iem.at]> An: pd-list@lists.iem.at[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[Pd-list@lists.iem.at] mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list%5Bhttps://lists.puredata.info/l...]
Pd-list@lists.iem.at[Pd-list@lists.iem.at] mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list%5Bhttps://lists.puredata.info/l...]
Pd-list@lists.iem.at[Pd-list@lists.iem.at] mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list%5Bhttps://lists.puredata.info/l...]
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
What do you think about the idea with a flag for changing the way creation arguments are forwarded? It would be really handy if you could write something like [clone -flag 100 my-abstraction 5 6 7] and $1 $2 $3 will be substituted by 5 6 7 instead of [N] 5 6. This way you could use existing abstractions as they are, without the need for writing a wrapper abstraction to handle the creation argument forwarding.
Christof
Gesendet: Dienstag, 17. Mai 2016 um 04:05 Uhr Von: "Miller Puckette" msp@ucsd.edu An: "Jaime Oliver" jaime.oliver2@gmail.com Cc: "Christof Ressi" christof.ressi@gmx.at, Pd-list pd-list@lists.iem.at Betreff: Re: [PD] [clone]'s instance number
Cool, taking this suggestion. At least for now it will work either way, but it's much more readable with the abstraction name first so I changed the help file to invoke it that way.
cheers Miller
On Wed, May 11, 2016 at 01:13:37PM -0400, Jaime Oliver wrote:
Well,
What would happen if instead of calling clone like:
[clone 16 my-abstraction 1 5 9]
we called it with:
[clone my-abstraction 16 1 5 9]
and then $1 seems quite appropriate.
?
J
On May 11, 2016, at 12:17 PM, Christof Ressi christof.ressi@gmx.at wrote:
I agree that $1 is most natural!
However, what about adding an additional flag -foo for [clone], which changes the way creation arguments are parsed? Passing -foo could ignore the object ID and rather forward creation arguments just as they are.
This wouldn't break the current behaviour of [clone], but provide some functionality to deal with ordinary abstractions more conveniently.
Christof
Gesendet: Mittwoch, 11. Mai 2016 um 18:06 Uhr Von: "Ivica Bukvic" ico@vt.edu An: "Miller Puckette" msp@ucsd.edu Cc: "IOhannes m zmoelnig" zmoelnig@iem.at, Pd-list pd-list@lists.iem.at, "Christof Ressi" christof.ressi@gmx.at Betreff: Re: [PD] [clone]'s instance number What about having an if statement that detects clone object and if so, compensates for $2 discrepancy and assigns $1 to it instead and increments from there? This way the discrepancy is internalized as opposed to something user needs to deal with. -- Ivica Ico Bukvic, D.M.A. Associate Professor Computer Music ICAT Senior Fellow Director -- DISIS, L2Ork Virginia Tech School of Performing Arts – 0141 Blacksburg, VA 24061 (540) 231-6139 ico@vt.edu www.performingarts.vt.edu[http://www.performingarts.vt.edu] disis.icat.vt.edu[http://disis.icat.vt.edu] l2ork.icat.vt.edu[http://l2ork.icat.vt.edu] ico.bukvic.net[http://ico.bukvic.net]
On May 11, 2016 11:50, "Miller Puckette" <msp@ucsd.edu[msp@ucsd.edu]> wrote:I gave this some thought but couldn't come up with anything more natural than the "$1" idea. It allows for changing the other arguments more easily than it would have been if the instance number were passed last. Also, somehow it felt more natural to have the instance number first.
If there's interest in the idea, I could add arrguments to change the behavior (such as putting $1 last instead of first)... Offhand I doubt that would get used much though.
cheers Miller
On Wed, May 11, 2016 at 05:26:21PM +0200, Christof Ressi wrote:
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[zmoelnig@iem.at]> An: pd-list@lists.iem.at[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[Pd-list@lists.iem.at] mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list%5Bhttps://lists.puredata.info/l...]
Pd-list@lists.iem.at[Pd-list@lists.iem.at] mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list%5Bhttps://lists.puredata.info/l...]
Pd-list@lists.iem.at[Pd-list@lists.iem.at] mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list%5Bhttps://lists.puredata.info/l...]
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
I'm not sure... would anyone ever use this feature? The patch in question would ahve to take arguments (if not, thre's no problem) but not use them to disambiguate the instances (because clone will set them all equal anyway). I have trouble imaginig anyone building a patch like that.
cheers Miller
On Wed, May 18, 2016 at 12:54:16AM +0200, Christof Ressi wrote:
What do you think about the idea with a flag for changing the way creation arguments are forwarded? It would be really handy if you could write something like [clone -flag 100 my-abstraction 5 6 7] and $1 $2 $3 will be substituted by 5 6 7 instead of [N] 5 6. This way you could use existing abstractions as they are, without the need for writing a wrapper abstraction to handle the creation argument forwarding.
Christof
Gesendet: Dienstag, 17. Mai 2016 um 04:05 Uhr Von: "Miller Puckette" msp@ucsd.edu An: "Jaime Oliver" jaime.oliver2@gmail.com Cc: "Christof Ressi" christof.ressi@gmx.at, Pd-list pd-list@lists.iem.at Betreff: Re: [PD] [clone]'s instance number
Cool, taking this suggestion. At least for now it will work either way, but it's much more readable with the abstraction name first so I changed the help file to invoke it that way.
cheers Miller
On Wed, May 11, 2016 at 01:13:37PM -0400, Jaime Oliver wrote:
Well,
What would happen if instead of calling clone like:
[clone 16 my-abstraction 1 5 9]
we called it with:
[clone my-abstraction 16 1 5 9]
and then $1 seems quite appropriate.
?
J
On May 11, 2016, at 12:17 PM, Christof Ressi christof.ressi@gmx.at wrote:
I agree that $1 is most natural!
However, what about adding an additional flag -foo for [clone], which changes the way creation arguments are parsed? Passing -foo could ignore the object ID and rather forward creation arguments just as they are.
This wouldn't break the current behaviour of [clone], but provide some functionality to deal with ordinary abstractions more conveniently.
Christof
Gesendet: Mittwoch, 11. Mai 2016 um 18:06 Uhr Von: "Ivica Bukvic" ico@vt.edu An: "Miller Puckette" msp@ucsd.edu Cc: "IOhannes m zmoelnig" zmoelnig@iem.at, Pd-list pd-list@lists.iem.at, "Christof Ressi" christof.ressi@gmx.at Betreff: Re: [PD] [clone]'s instance number What about having an if statement that detects clone object and if so, compensates for $2 discrepancy and assigns $1 to it instead and increments from there? This way the discrepancy is internalized as opposed to something user needs to deal with. -- Ivica Ico Bukvic, D.M.A. Associate Professor Computer Music ICAT Senior Fellow Director -- DISIS, L2Ork Virginia Tech School of Performing Arts – 0141 Blacksburg, VA 24061 (540) 231-6139 ico@vt.edu www.performingarts.vt.edu[http://www.performingarts.vt.edu] disis.icat.vt.edu[http://disis.icat.vt.edu] l2ork.icat.vt.edu[http://l2ork.icat.vt.edu] ico.bukvic.net[http://ico.bukvic.net]
On May 11, 2016 11:50, "Miller Puckette" <msp@ucsd.edu[msp@ucsd.edu]> wrote:I gave this some thought but couldn't come up with anything more natural than the "$1" idea. It allows for changing the other arguments more easily than it would have been if the instance number were passed last. Also, somehow it felt more natural to have the instance number first.
If there's interest in the idea, I could add arrguments to change the behavior (such as putting $1 last instead of first)... Offhand I doubt that would get used much though.
cheers Miller
On Wed, May 11, 2016 at 05:26:21PM +0200, Christof Ressi wrote:
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[zmoelnig@iem.at]> An: pd-list@lists.iem.at[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[Pd-list@lists.iem.at] mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list%5Bhttps://lists.puredata.info/l...]
Pd-list@lists.iem.at[Pd-list@lists.iem.at] mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list%5Bhttps://lists.puredata.info/l...]
Pd-list@lists.iem.at[Pd-list@lists.iem.at] mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list%5Bhttps://lists.puredata.info/l...]
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
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
you can still disambiguate, because incoming messages are dispatched by the instance number and outgoing messages are prepended with it!
My suggestion was mainly concerning all abstractions that work with inlets and outlets (as opposed to sends and receives), where you basically pass a message and get something out. This could be anything, from simple message filtering to a perlin noise generator. Or also existing audio modules that work with a message inlet. If there was such a flag, you could take any of these abstractions as they are, control them separately by prepending the instance number and route the message output (or use the sum of the audio output).
I guess, people will use [clone] mainly for voice management for synthesizers, granular synthesis, complicated nested patches etc., but I also see a great potential for massive data generation by using existing simple abstractions and cloning them.
Personally, I have many abstractions I would like to use with [clone], but either I'd have to rewrite them or make a wrapper abstraction. It's not a big deal, it's just that an alternative forwarding mode would provide some additional convenience (and could also encourage other usages for [clone]).
Anyway, I can totally live without this feature, but would be happy to have it :-).
Gesendet: Mittwoch, 18. Mai 2016 um 02:35 Uhr Von: "Miller Puckette" msp@ucsd.edu An: "Christof Ressi" christof.ressi@gmx.at Cc: Pd-list pd-list@lists.iem.at Betreff: Re: [PD] [clone]'s instance number
I'm not sure... would anyone ever use this feature? The patch in question would ahve to take arguments (if not, thre's no problem) but not use them to disambiguate the instances (because clone will set them all equal anyway). I have trouble imaginig anyone building a patch like that.
cheers Miller
On Wed, May 18, 2016 at 12:54:16AM +0200, Christof Ressi wrote:
What do you think about the idea with a flag for changing the way creation arguments are forwarded? It would be really handy if you could write something like [clone -flag 100 my-abstraction 5 6 7] and $1 $2 $3 will be substituted by 5 6 7 instead of [N] 5 6. This way you could use existing abstractions as they are, without the need for writing a wrapper abstraction to handle the creation argument forwarding.
Christof
Gesendet: Dienstag, 17. Mai 2016 um 04:05 Uhr Von: "Miller Puckette" msp@ucsd.edu An: "Jaime Oliver" jaime.oliver2@gmail.com Cc: "Christof Ressi" christof.ressi@gmx.at, Pd-list pd-list@lists.iem.at Betreff: Re: [PD] [clone]'s instance number
Cool, taking this suggestion. At least for now it will work either way, but it's much more readable with the abstraction name first so I changed the help file to invoke it that way.
cheers Miller
On Wed, May 11, 2016 at 01:13:37PM -0400, Jaime Oliver wrote:
Well,
What would happen if instead of calling clone like:
[clone 16 my-abstraction 1 5 9]
we called it with:
[clone my-abstraction 16 1 5 9]
and then $1 seems quite appropriate.
?
J
On May 11, 2016, at 12:17 PM, Christof Ressi christof.ressi@gmx.at wrote:
I agree that $1 is most natural!
However, what about adding an additional flag -foo for [clone], which changes the way creation arguments are parsed? Passing -foo could ignore the object ID and rather forward creation arguments just as they are.
This wouldn't break the current behaviour of [clone], but provide some functionality to deal with ordinary abstractions more conveniently.
Christof
Gesendet: Mittwoch, 11. Mai 2016 um 18:06 Uhr Von: "Ivica Bukvic" ico@vt.edu An: "Miller Puckette" msp@ucsd.edu Cc: "IOhannes m zmoelnig" zmoelnig@iem.at, Pd-list pd-list@lists.iem.at, "Christof Ressi" christof.ressi@gmx.at Betreff: Re: [PD] [clone]'s instance number What about having an if statement that detects clone object and if so, compensates for $2 discrepancy and assigns $1 to it instead and increments from there? This way the discrepancy is internalized as opposed to something user needs to deal with. -- Ivica Ico Bukvic, D.M.A. Associate Professor Computer Music ICAT Senior Fellow Director -- DISIS, L2Ork Virginia Tech School of Performing Arts – 0141 Blacksburg, VA 24061 (540) 231-6139 ico@vt.edu www.performingarts.vt.edu[http://www.performingarts.vt.edu] disis.icat.vt.edu[http://disis.icat.vt.edu] l2ork.icat.vt.edu[http://l2ork.icat.vt.edu] ico.bukvic.net[http://ico.bukvic.net]
On May 11, 2016 11:50, "Miller Puckette" <msp@ucsd.edu[msp@ucsd.edu]> wrote:I gave this some thought but couldn't come up with anything more natural than the "$1" idea. It allows for changing the other arguments more easily than it would have been if the instance number were passed last. Also, somehow it felt more natural to have the instance number first.
If there's interest in the idea, I could add arrguments to change the behavior (such as putting $1 last instead of first)... Offhand I doubt that would get used much though.
cheers Miller
On Wed, May 11, 2016 at 05:26:21PM +0200, Christof Ressi wrote:
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[zmoelnig@iem.at]> > An: pd-list@lists.iem.at[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[Pd-list@lists.iem.at] mailing list > UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list%5Bhttps://lists.puredata.info/l...] >
Pd-list@lists.iem.at[Pd-list@lists.iem.at] mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list%5Bhttps://lists.puredata.info/l...]
Pd-list@lists.iem.at[Pd-list@lists.iem.at] mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list%5Bhttps://lists.puredata.info/l...]
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
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
I might be confused about something here. Is the idea of setting $1 as the [clone] instance number so that the abstraction can know its instance value from inside? Any communication from the outside (including between instances) should probably be done via [clone] itself since all messages are (or can be) addressed by the instance number. Or is the idea that you should be able to set up a [r $1-foo] inside instances for communication?
On Tue, May 17, 2016 at 9:44 PM, Christof Ressi christof.ressi@gmx.at wrote:
you can still disambiguate, because incoming messages are dispatched by the instance number and outgoing messages are prepended with it!
My suggestion was mainly concerning all abstractions that work with inlets and outlets (as opposed to sends and receives), where you basically pass a message and get something out. This could be anything, from simple message filtering to a perlin noise generator. Or also existing audio modules that work with a message inlet. If there was such a flag, you could take any of these abstractions as they are, control them separately by prepending the instance number and route the message output (or use the sum of the audio output).
I guess, people will use [clone] mainly for voice management for synthesizers, granular synthesis, complicated nested patches etc., but I also see a great potential for massive data generation by using existing simple abstractions and cloning them.
Personally, I have many abstractions I would like to use with [clone], but either I'd have to rewrite them or make a wrapper abstraction. It's not a big deal, it's just that an alternative forwarding mode would provide some additional convenience (and could also encourage other usages for [clone]).
Anyway, I can totally live without this feature, but would be happy to have it :-).
Gesendet: Mittwoch, 18. Mai 2016 um 02:35 Uhr Von: "Miller Puckette" msp@ucsd.edu An: "Christof Ressi" christof.ressi@gmx.at Cc: Pd-list pd-list@lists.iem.at Betreff: Re: [PD] [clone]'s instance number
I'm not sure... would anyone ever use this feature? The patch in
question
would ahve to take arguments (if not, thre's no problem) but not use
them to
disambiguate the instances (because clone will set them all equal
anyway).
I have trouble imaginig anyone building a patch like that.
cheers Miller
On Wed, May 18, 2016 at 12:54:16AM +0200, Christof Ressi wrote:
What do you think about the idea with a flag for changing the way
creation arguments are forwarded? It would be really handy if you could write something like
[clone -flag 100 my-abstraction 5 6 7] and $1 $2 $3 will be
substituted by 5 6 7 instead of [N] 5 6. This way you could use existing abstractions as they are, without the need for writing a wrapper abstraction to handle the creation argument forwarding.
Christof
Gesendet: Dienstag, 17. Mai 2016 um 04:05 Uhr Von: "Miller Puckette" msp@ucsd.edu An: "Jaime Oliver" jaime.oliver2@gmail.com Cc: "Christof Ressi" christof.ressi@gmx.at, Pd-list <
pd-list@lists.iem.at>
Betreff: Re: [PD] [clone]'s instance number
Cool, taking this suggestion. At least for now it will work either
way,
but it's much more readable with the abstraction name first so I
changed the
help file to invoke it that way.
cheers Miller
On Wed, May 11, 2016 at 01:13:37PM -0400, Jaime Oliver wrote:
Well,
What would happen if instead of calling clone like:
[clone 16 my-abstraction 1 5 9]
we called it with:
[clone my-abstraction 16 1 5 9]
and then $1 seems quite appropriate.
?
J
On May 11, 2016, at 12:17 PM, Christof Ressi <
christof.ressi@gmx.at> wrote:
I agree that $1 is most natural!
However, what about adding an additional flag -foo for [clone],
which changes the way creation arguments are parsed?
Passing -foo could ignore the object ID and rather forward
creation arguments just as they are.
This wouldn't break the current behaviour of [clone], but
provide some functionality to deal with ordinary abstractions more conveniently.
Christof
Gesendet: Mittwoch, 11. Mai 2016 um 18:06 Uhr Von: "Ivica Bukvic" ico@vt.edu An: "Miller Puckette" msp@ucsd.edu Cc: "IOhannes m zmoelnig" zmoelnig@iem.at, Pd-list <
pd-list@lists.iem.at>, "Christof Ressi" christof.ressi@gmx.at
Betreff: Re: [PD] [clone]'s instance number What about having an if statement that detects clone object and
if so, compensates for $2 discrepancy and assigns $1 to it instead and increments from there? This way the discrepancy is internalized as opposed to something user needs to deal with.
-- Ivica Ico Bukvic, D.M.A. Associate Professor Computer Music ICAT Senior Fellow Director -- DISIS, L2Ork Virginia Tech School of Performing Arts – 0141 Blacksburg, VA 24061 (540) 231-6139 ico@vt.edu www.performingarts.vt.edu[http://www.performingarts.vt.edu] disis.icat.vt.edu[http://disis.icat.vt.edu] l2ork.icat.vt.edu[http://l2ork.icat.vt.edu] ico.bukvic.net[http://ico.bukvic.net]
On May 11, 2016 11:50, "Miller Puckette" <msp@ucsd.edu[
msp@ucsd.edu]> wrote:I gave this some thought but couldn't come up with anything more natural than
the "$1" idea. It allows for changing the other arguments more
easily than
it would have been if the instance number were passed last.
Also, somehow
it felt more natural to have the instance number first.
If there's interest in the idea, I could add arrguments to
change the
behavior (such as putting $1 last instead of first)... Offhand
I doubt that
would get used much though.
cheers Miller
On Wed, May 11, 2016 at 05:26:21PM +0200, Christof Ressi wrote: > 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[zmoelnig@iem.at]> >> An: pd-list@lists.iem.at[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[Pd-list@lists.iem.at] mailing list >> UNSUBSCRIBE and account-management ->
https://lists.puredata.info/listinfo/pd-list%5Bhttps://lists.puredata.info/l...]
>> > > _______________________________________________ > Pd-list@lists.iem.at[Pd-list@lists.iem.at] mailing list > UNSUBSCRIBE and account-management ->
https://lists.puredata.info/listinfo/pd-list%5Bhttps://lists.puredata.info/l...]
Pd-list@lists.iem.at[Pd-list@lists.iem.at] mailing list UNSUBSCRIBE and account-management ->
https://lists.puredata.info/listinfo/pd-list%5Bhttps://lists.puredata.info/l...]
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
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
I might be confused about something here. Is the idea of setting $1 as the [clone] instance number so that the abstraction can know its instance value from inside?
yes. I think that is the main purpose.
Any communication from the outside (including between instances) should probably be done via [clone] itself since all messages are (or can be) addressed by the instance number. Or is the idea that you should be able to set up a [r $1-foo] inside instances for communication?
There would be no reason to do either (inlet or send/receive) I think as both work.
best,
J
On Tue, May 17, 2016 at 9:44 PM, Christof Ressi <christof.ressi@gmx.at mailto:christof.ressi@gmx.at> wrote: you can still disambiguate, because incoming messages are dispatched by the instance number and outgoing messages are prepended with it!
My suggestion was mainly concerning all abstractions that work with inlets and outlets (as opposed to sends and receives), where you basically pass a message and get something out. This could be anything, from simple message filtering to a perlin noise generator. Or also existing audio modules that work with a message inlet. If there was such a flag, you could take any of these abstractions as they are, control them separately by prepending the instance number and route the message output (or use the sum of the audio output).
I guess, people will use [clone] mainly for voice management for synthesizers, granular synthesis, complicated nested patches etc., but I also see a great potential for massive data generation by using existing simple abstractions and cloning them.
Personally, I have many abstractions I would like to use with [clone], but either I'd have to rewrite them or make a wrapper abstraction. It's not a big deal, it's just that an alternative forwarding mode would provide some additional convenience (and could also encourage other usages for [clone]).
Anyway, I can totally live without this feature, but would be happy to have it :-).
Gesendet: Mittwoch, 18. Mai 2016 um 02:35 Uhr Von: "Miller Puckette" <msp@ucsd.edu mailto:msp@ucsd.edu> An: "Christof Ressi" <christof.ressi@gmx.at mailto:christof.ressi@gmx.at> Cc: Pd-list <pd-list@lists.iem.at mailto:pd-list@lists.iem.at> Betreff: Re: [PD] [clone]'s instance number
I'm not sure... would anyone ever use this feature? The patch in question would ahve to take arguments (if not, thre's no problem) but not use them to disambiguate the instances (because clone will set them all equal anyway). I have trouble imaginig anyone building a patch like that.
cheers Miller
On Wed, May 18, 2016 at 12:54:16AM +0200, Christof Ressi wrote:
What do you think about the idea with a flag for changing the way creation arguments are forwarded? It would be really handy if you could write something like [clone -flag 100 my-abstraction 5 6 7] and $1 $2 $3 will be substituted by 5 6 7 instead of [N] 5 6. This way you could use existing abstractions as they are, without the need for writing a wrapper abstraction to handle the creation argument forwarding.
Christof
Gesendet: Dienstag, 17. Mai 2016 um 04:05 Uhr Von: "Miller Puckette" <msp@ucsd.edu mailto:msp@ucsd.edu> An: "Jaime Oliver" <jaime.oliver2@gmail.com mailto:jaime.oliver2@gmail.com> Cc: "Christof Ressi" <christof.ressi@gmx.at mailto:christof.ressi@gmx.at>, Pd-list <pd-list@lists.iem.at mailto:pd-list@lists.iem.at> Betreff: Re: [PD] [clone]'s instance number
Cool, taking this suggestion. At least for now it will work either way, but it's much more readable with the abstraction name first so I changed the help file to invoke it that way.
cheers Miller
On Wed, May 11, 2016 at 01:13:37PM -0400, Jaime Oliver wrote:
Well,
What would happen if instead of calling clone like:
[clone 16 my-abstraction 1 5 9]
we called it with:
[clone my-abstraction 16 1 5 9]
and then $1 seems quite appropriate.
?
J
On May 11, 2016, at 12:17 PM, Christof Ressi <christof.ressi@gmx.at mailto:christof.ressi@gmx.at> wrote:
I agree that $1 is most natural!
However, what about adding an additional flag -foo for [clone], which changes the way creation arguments are parsed? Passing -foo could ignore the object ID and rather forward creation arguments just as they are.
This wouldn't break the current behaviour of [clone], but provide some functionality to deal with ordinary abstractions more conveniently.
Christof
Gesendet: Mittwoch, 11. Mai 2016 um 18:06 Uhr Von: "Ivica Bukvic" <ico@vt.edu mailto:ico@vt.edu> An: "Miller Puckette" <msp@ucsd.edu mailto:msp@ucsd.edu> Cc: "IOhannes m zmoelnig" <zmoelnig@iem.at mailto:zmoelnig@iem.at>, Pd-list <pd-list@lists.iem.at mailto:pd-list@lists.iem.at>, "Christof Ressi" <christof.ressi@gmx.at mailto:christof.ressi@gmx.at> Betreff: Re: [PD] [clone]'s instance number What about having an if statement that detects clone object and if so, compensates for $2 discrepancy and assigns $1 to it instead and increments from there? This way the discrepancy is internalized as opposed to something user needs to deal with. -- Ivica Ico Bukvic, D.M.A. Associate Professor Computer Music ICAT Senior Fellow Director -- DISIS, L2Ork Virginia Tech School of Performing Arts – 0141 Blacksburg, VA 24061 (540) 231-6139 tel:%28540%29%20231-6139 ico@vt.edu mailto:ico@vt.edu www.performingarts.vt.edu http://www.performingarts.vt.edu/[http://www.performingarts.vt.edu http://www.performingarts.vt.edu/] disis.icat.vt.edu http://disis.icat.vt.edu/[http://disis.icat.vt.edu http://disis.icat.vt.edu/] l2ork.icat.vt.edu http://l2ork.icat.vt.edu/[http://l2ork.icat.vt.edu http://l2ork.icat.vt.edu/] ico.bukvic.net http://ico.bukvic.net/[http://ico.bukvic.net http://ico.bukvic.net/]
On May 11, 2016 11:50, "Miller Puckette" <msp@ucsd.edu mailto:msp@ucsd.edu[msp@ucsd.edu mailto:msp@ucsd.edu]> wrote:I gave this some thought but couldn't come up with anything more natural than the "$1" idea. It allows for changing the other arguments more easily than it would have been if the instance number were passed last. Also, somehow it felt more natural to have the instance number first.
If there's interest in the idea, I could add arrguments to change the behavior (such as putting $1 last instead of first)... Offhand I doubt that would get used much though.
cheers Miller
On Wed, May 11, 2016 at 05:26:21PM +0200, Christof Ressi wrote: > 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 mailto:zmoelnig@iem.at[zmoelnig@iem.at mailto:zmoelnig@iem.at]> >> An: pd-list@lists.iem.at mailto:pd-list@lists.iem.at[pd-list@lists.iem.at mailto: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 mailto:Pd-list@lists.iem.at[Pd-list@lists.iem.at mailto:Pd-list@lists.iem.at] mailing list >> UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list%5Bhttps://lists.puredata.info/l...] https://lists.puredata.info/listinfo/pd-list[https://lists.puredata.info/listinfo/pd-list] >> > > _______________________________________________ > Pd-list@lists.iem.at mailto:Pd-list@lists.iem.at[Pd-list@lists.iem.at mailto:Pd-list@lists.iem.at] mailing list > UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list%5Bhttps://lists.puredata.info/l...] https://lists.puredata.info/listinfo/pd-list[https://lists.puredata.info/listinfo/pd-list]
Pd-list@lists.iem.at mailto:Pd-list@lists.iem.at[Pd-list@lists.iem.at mailto:Pd-list@lists.iem.at] mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list%5Bhttps://lists.puredata.info/l...] https://lists.puredata.info/listinfo/pd-list[https://lists.puredata.info/listinfo/pd-list]
Pd-list@lists.iem.at mailto:Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list https://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailto:Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list https://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailto:Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list https://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailto:Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list 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
I see your point, the abstraction need not know it's instance number since only the messages meant for it would be dispatched to it.. If you don't care about using sends directed to a specific abstraction then the $1 does nothing for you and if the flag to clone could ditch the $1 to instance setting and just set the arguments to the abstraction [clone -flag blah 20 1 2 3] makes 20 copies of blah with args $1=1 $2=2.. You could use more of your existing abstractions as is, using their args the same way with or without clone.
I'm warming up to that idea.
Alex
On May 17, 2016 6:44:51 PM PDT, Christof Ressi christof.ressi@gmx.at wrote:
you can still disambiguate, because incoming messages are dispatched by the instance number and outgoing messages are prepended with it!
My suggestion was mainly concerning all abstractions that work with inlets and outlets (as opposed to sends and receives), where you basically pass a message and get something out. This could be anything, from simple message filtering to a perlin noise generator. Or also existing audio modules that work with a message inlet. If there was such a flag, you could take any of these abstractions as they are, control them separately by prepending the instance number and route the message output (or use the sum of the audio output).
I guess, people will use [clone] mainly for voice management for synthesizers, granular synthesis, complicated nested patches etc., but I also see a great potential for massive data generation by using existing simple abstractions and cloning them.
Personally, I have many abstractions I would like to use with [clone], but either I'd have to rewrite them or make a wrapper abstraction. It's not a big deal, it's just that an alternative forwarding mode would provide some additional convenience (and could also encourage other usages for [clone]).
Anyway, I can totally live without this feature, but would be happy to have it :-).
Gesendet: Mittwoch, 18. Mai 2016 um 02:35 Uhr Von: "Miller Puckette" msp@ucsd.edu An: "Christof Ressi" christof.ressi@gmx.at Cc: Pd-list pd-list@lists.iem.at Betreff: Re: [PD] [clone]'s instance number
I'm not sure... would anyone ever use this feature? The patch in
question
would ahve to take arguments (if not, thre's no problem) but not use
them to
disambiguate the instances (because clone will set them all equal
anyway).
I have trouble imaginig anyone building a patch like that.
cheers Miller
On Wed, May 18, 2016 at 12:54:16AM +0200, Christof Ressi wrote:
What do you think about the idea with a flag for changing the way
creation arguments are forwarded? It would be really handy if you could write something like
[clone -flag 100 my-abstraction 5 6 7] and $1 $2 $3 will be
substituted by 5 6 7 instead of [N] 5 6. This way you could use existing abstractions as they are, without the need for writing a wrapper abstraction to handle the creation argument forwarding.
Christof
Gesendet: Dienstag, 17. Mai 2016 um 04:05 Uhr Von: "Miller Puckette" msp@ucsd.edu An: "Jaime Oliver" jaime.oliver2@gmail.com Cc: "Christof Ressi" christof.ressi@gmx.at, Pd-list
Betreff: Re: [PD] [clone]'s instance number
Cool, taking this suggestion. At least for now it will work
either way,
but it's much more readable with the abstraction name first so I
changed the
help file to invoke it that way.
cheers Miller
On Wed, May 11, 2016 at 01:13:37PM -0400, Jaime Oliver wrote:
Well,
What would happen if instead of calling clone like:
[clone 16 my-abstraction 1 5 9]
we called it with:
[clone my-abstraction 16 1 5 9]
and then $1 seems quite appropriate.
?
J
On May 11, 2016, at 12:17 PM, Christof Ressi
christof.ressi@gmx.at wrote:
I agree that $1 is most natural!
However, what about adding an additional flag -foo for
[clone], which changes the way creation arguments are parsed?
Passing -foo could ignore the object ID and rather forward
creation arguments just as they are.
This wouldn't break the current behaviour of [clone], but
provide some functionality to deal with ordinary abstractions more conveniently.
Christof
Gesendet: Mittwoch, 11. Mai 2016 um 18:06 Uhr Von: "Ivica Bukvic" ico@vt.edu An: "Miller Puckette" msp@ucsd.edu Cc: "IOhannes m zmoelnig" zmoelnig@iem.at, Pd-list
pd-list@lists.iem.at, "Christof Ressi" christof.ressi@gmx.at
Betreff: Re: [PD] [clone]'s instance number What about having an if statement that detects clone object
and if so, compensates for $2 discrepancy and assigns $1 to it instead and increments from there? This way the discrepancy is internalized as opposed to something user needs to deal with.
-- Ivica Ico Bukvic, D.M.A. Associate Professor Computer Music ICAT Senior Fellow Director -- DISIS, L2Ork Virginia Tech School of Performing Arts – 0141 Blacksburg, VA 24061 (540) 231-6139 ico@vt.edu www.performingarts.vt.edu[http://www.performingarts.vt.edu] disis.icat.vt.edu[http://disis.icat.vt.edu] l2ork.icat.vt.edu[http://l2ork.icat.vt.edu] ico.bukvic.net[http://ico.bukvic.net]
On May 11, 2016 11:50, "Miller Puckette"
<msp@ucsd.edu[msp@ucsd.edu]> wrote:I gave this some thought but couldn't come up with anything more natural than
the "$1" idea. It allows for changing the other arguments
more easily than
it would have been if the instance number were passed last.
Also, somehow
it felt more natural to have the instance number first.
If there's interest in the idea, I could add arrguments to
change the
behavior (such as putting $1 last instead of first)...
Offhand I doubt that
would get used much though.
cheers Miller
On Wed, May 11, 2016 at 05:26:21PM +0200, Christof Ressi
wrote:
> 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[zmoelnig@iem.at]>
>> An: pd-list@lists.iem.at[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[Pd-list@lists.iem.at] mailing list >> UNSUBSCRIBE and account-management ->
https://lists.puredata.info/listinfo/pd-list%5Bhttps://lists.puredata.info/l...]
>> > > _______________________________________________ > Pd-list@lists.iem.at[Pd-list@lists.iem.at] mailing list > UNSUBSCRIBE and account-management ->
https://lists.puredata.info/listinfo/pd-list%5Bhttps://lists.puredata.info/l...]
Pd-list@lists.iem.at[Pd-list@lists.iem.at] mailing list UNSUBSCRIBE and account-management ->
https://lists.puredata.info/listinfo/pd-list%5Bhttps://lists.puredata.info/l...]
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
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
I wonder if there's a way to map instance numbers to $0 values in instances. Suppose you had:
[clone -receive foo 16 abstraction 1 2 3]
where 1 2 3 are mapped to $1 $2 $3 inside the instances, respectively.
[clone] makes 16 instances. Then in your abstraction you have [r $0-foo], and [4 <message>(--[s foo] from outside would be received by the [r $0-foo] inside the fourth instance.
The complicated thing here is how to make this work:
[clone -receive $0-foo 16 abstraction 1 2 3]
Since the instances don't know their parent's $0-value, you'd need to modify your abstraction to contain [r $0-$4-foo], and then make [clone -receive $0-foo 16 abstraction 1 2 3 $0]. This is complicated -- probably too complicated -- but the advantage would be that you'd need to make minimal changes to the abstraction. The levels of locality are handled by the user, and it would be much less disruptive to add an extra argument at the end when needed than to get [clone] to try to handle it automatically with the current $1 stuff.
But again, I might be missing something in the design and intended use of the $1 mapping.
On Wed, May 18, 2016 at 10:20 AM, Alex Norman x37v.alex@gmail.com wrote:
I see your point, the abstraction need not know it's instance number since only the messages meant for it would be dispatched to it.. If you don't care about using sends directed to a specific abstraction then the $1 does nothing for you and if the flag to clone could ditch the $1 to instance setting and just set the arguments to the abstraction [clone -flag blah 20 1 2 3] makes 20 copies of blah with args $1=1 $2=2.. You could use more of your existing abstractions as is, using their args the same way with or without clone.
I'm warming up to that idea.
Alex
On May 17, 2016 6:44:51 PM PDT, Christof Ressi christof.ressi@gmx.at wrote:
you can still disambiguate, because incoming messages are dispatched by the instance number and outgoing messages are prepended with it!
My suggestion was mainly concerning all abstractions that work with inlets and outlets (as opposed to sends and receives), where you basically pass a message and get something out. This could be anything, from simple message filtering to a perlin noise generator. Or also existing audio modules that work with a message inlet. If there was such a flag, you could take any of these abstractions as they are, control them separately by prepending the instance number and route the message output (or use the sum of the audio output).
I guess, people will use [clone] mainly for voice management for synthesizers, granular synthesis, complicated nested patches etc., but I also see a great potential for massive data generation by using existing simple abstractions and cloning them.
Personally, I have many abstractions I would like to use with [clone], but either I'd have to rewrite them or make a wrapper abstraction. It's not a big deal, it's just that an alternative forwarding mode would provide some additional convenience (and could also encourage other usages for [clone]).
Anyway, I can totally live without this feature, but would be happy to have it :-).
Gesendet: Mittwoch, 18. Mai 2016 um 02:35 Uhr
Von: "Miller Puckette" msp@ucsd.edu An: "Christof Ressi" christof.ressi@gmx.at Cc: Pd-list pd-list@lists.iem.at Betreff: Re: [PD] [clone]'s instance number
I'm not sure... would anyone ever use this feature? The patch in question would ahve to take arguments (if not, thre's no problem) but not use them to disambiguate the instances (because clone will set them all equal anyway). I have trouble imaginig anyone building a patch like that.
cheers Miller
On Wed, May 18, 2016 at 12:54:16AM +0200, Christof Ressi wrote:
What do you think about the idea with a flag for changing the way creation arguments are forwarded? It would be really handy if you could write something like [clone -flag 100 my-abstraction 5 6 7] and $1 $2 $3 will be substituted by 5 6 7 instead of [N] 5 6. This way you could use existing abstractions as they are, without the need for writing a wrapper abstraction to handle the creation argument forwarding.
Christof
Gesendet: Dienstag, 17. Mai 2016 um 04:05 Uhr
Von: "Miller Puckette" msp@ucsd.edu An: "Jaime Oliver" jaime.oliver2@gmail.com Cc: "Christof Ressi" christof.ressi@gmx.at, Pd-list pd-list@lists.iem.at Betreff: Re: [PD] [clone]'s instance number
Cool, taking this suggestion. At least for now it will work either way, but it's much more readable with the abstraction name first so I changed the help file to invoke it that way.
cheers Miller
On Wed, May 11, 2016 at 01:13:37PM -0400, Jaime Oliver wrote:
Well,
What would happen if instead of calling clone like:
[clone 16 my-abstraction 1 5 9]
we called it with:
[clone my-abstraction 16 1 5 9]
and then $1 seems quite appropriate.
?
J
On May 11, 2016, at 12:17 PM, Christof Ressi christof.ressi@gmx.at wrote: > > I agree that $1 is most natural! > > However, what about adding an additional flag -foo for [clone], which changes the way creation arguments are parsed? > Passing -foo could ignore the object ID and rather forward creation arguments just as they are. > > This wouldn't break the current behaviour of [clone], but provide some functionality to deal with ordinary abstractions more conveniently. > > Christof > > > > > > > > Gesendet: Mittwoch, 11. Mai 2016 um 18:06 Uhr > Von: "Ivica Bukvic" ico@vt.edu > An: "Miller Puckette" msp@ucsd.edu > Cc: "IOhannes m zmoelnig" zmoelnig@iem.at, Pd-list pd-list@lists.iem.at, "Christof Ressi" christof.ressi@gmx.at > Betreff: Re: [PD] [clone]'s instance number > What about > having an if statement that detects clone object and if so, compensates for $2 discrepancy and assigns $1 to it instead and increments from there? This way the discrepancy is internalized as opposed to something user needs to deal with. > -- > Ivica Ico Bukvic, D.M.A. > Associate Professor > Computer Music > ICAT Senior Fellow > Director -- DISIS, L2Ork > Virginia Tech > School of Performing Arts – 0141 > Blacksburg, VA 24061 > (540) 231-6139 > ico@vt.edu > www.performingarts.vt.edu[http://www.performingarts.vt.edu] > disis.icat.vt.edu[http://disis.icat.vt.edu] > l2ork.icat.vt.edu[http://l2ork.icat.vt.edu] > ico.bukvic.net[http://ico.bukvic.net] > > On May 11, 2016 11:50, "Miller Puckette" <msp@ucsd.edu[msp@ucsd.edu]> wrote:I gave this some thought but couldn't come up with anything more natural than > the "$1" idea. It allows for changing the other arguments more easily than > it would have been if the instance number were passed last. Also, somehow > it felt more natural to have the instance number first. > > If there's interest in the idea, I could add arrguments to change the > behavior (such as putting $1 last instead of first)... Offhand I doubt that > would get used much though. > > cheers > Miller > > > > On Wed, May 11, 2016 at 05:26:21PM +0200, Christof Ressi wrote: > >> 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[zmoelnig@iem.at]> >>> An: pd-list@lists.iem.at[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[Pd-list@lists.iem.at] mailing list >>> UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list%5Bhttps://lists.puredata.info/l...] >>> >>> >> ------------------------------ >> >> Pd-list@lists.iem.at[Pd-list@lists.iem.at] mailing list >> UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list%5Bhttps://lists.puredata.info/l...] >> > > ------------------------------ > > Pd-list@lists.iem.at[Pd-list@lists.iem.at] mailing list > UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list%5Bhttps://lists.puredata.info/l...] > > ------------------------------ > > 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
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
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
So clearly the point is to make it so that abstractions are unaware of being instantiated via [my-abstraction-name 1 2 3] or [clone my-abstraction-name 16 1 2 3]
Inside an abstraction you could have a [r $0-foo] but how do you know $0 outside of the abstraction in either case? My guess is that you'd more often than not use $1 for that [r $1-foo] and clone just works as is without the new flag we're talking about.
I think sending |4 message( into [s foo] shouldn't do any remapping, but I could see some special message going to a clone.
something like:
|send 4 $0-foo message( -> [clone my-abstraction-name 16 1 2 3] (somehow escaping the $0) which would remap the $0 to instance 4's $0 [say its 1021] and then broadcast the message |1021-foo message(
but either way I'm not sure how you'd use the [r $0-foo] from outside the abstraction in the case where you're not using clone..
On Wed, May 18, 2016 at 9:41 AM, Matt Barber brbrofsvl@gmail.com wrote:
I wonder if there's a way to map instance numbers to $0 values in instances. Suppose you had:
[clone -receive foo 16 abstraction 1 2 3]
where 1 2 3 are mapped to $1 $2 $3 inside the instances, respectively.
[clone] makes 16 instances. Then in your abstraction you have [r $0-foo], and [4 <message>(--[s foo] from outside would be received by the [r $0-foo] inside the fourth instance.
The complicated thing here is how to make this work:
[clone -receive $0-foo 16 abstraction 1 2 3]
Since the instances don't know their parent's $0-value, you'd need to modify your abstraction to contain [r $0-$4-foo], and then make [clone -receive $0-foo 16 abstraction 1 2 3 $0]. This is complicated -- probably too complicated -- but the advantage would be that you'd need to make minimal changes to the abstraction. The levels of locality are handled by the user, and it would be much less disruptive to add an extra argument at the end when needed than to get [clone] to try to handle it automatically with the current $1 stuff.
But again, I might be missing something in the design and intended use of the $1 mapping.
On Wed, May 18, 2016 at 10:20 AM, Alex Norman x37v.alex@gmail.com wrote:
I see your point, the abstraction need not know it's instance number since only the messages meant for it would be dispatched to it.. If you don't care about using sends directed to a specific abstraction then the $1 does nothing for you and if the flag to clone could ditch the $1 to instance setting and just set the arguments to the abstraction [clone -flag blah 20 1 2 3] makes 20 copies of blah with args $1=1 $2=2.. You could use more of your existing abstractions as is, using their args the same way with or without clone.
I'm warming up to that idea.
Alex
On May 17, 2016 6:44:51 PM PDT, Christof Ressi christof.ressi@gmx.at wrote:
you can still disambiguate, because incoming messages are dispatched by the instance number and outgoing messages are prepended with it!
My suggestion was mainly concerning all abstractions that work with inlets and outlets (as opposed to sends and receives), where you basically pass a message and get something out. This could be anything, from simple message filtering to a perlin noise generator. Or also existing audio modules that work with a message inlet. If there was such a flag, you could take any of these abstractions as they are, control them separately by prepending the instance number and route the message output (or use the sum of the audio output).
I guess, people will use [clone] mainly for voice management for synthesizers, granular synthesis, complicated nested patches etc., but I also see a great potential for massive data generation by using existing simple abstractions and cloning them.
Personally, I have many abstractions I would like to use with [clone], but either I'd have to rewrite them or make a wrapper abstraction. It's not a big deal, it's just that an alternative forwarding mode would provide some additional convenience (and could also encourage other usages for [clone]).
Anyway, I can totally live without this feature, but would be happy to have it :-).
Gesendet: Mittwoch, 18. Mai 2016 um 02:35 Uhr
Von: "Miller Puckette" msp@ucsd.edu An: "Christof Ressi" christof.ressi@gmx.at Cc: Pd-list pd-list@lists.iem.at Betreff: Re: [PD] [clone]'s instance number
I'm not sure... would anyone ever use this feature? The patch in question would ahve to take arguments (if not, thre's no problem) but not use them to disambiguate the instances (because clone will set them all equal anyway). I have trouble imaginig anyone building a patch like that.
cheers Miller
On Wed, May 18, 2016 at 12:54:16AM +0200, Christof Ressi wrote:
What do you think about the idea with a flag for changing the way creation arguments are forwarded? It would be really handy if you could write something like [clone -flag 100 my-abstraction 5 6 7] and $1 $2 $3 will be substituted by 5 6 7 instead of [N] 5 6. This way you could use existing abstractions as they are, without the need for writing a wrapper abstraction to handle the creation argument forwarding.
Christof
Gesendet: Dienstag, 17. Mai 2016 um 04:05 Uhr
Von: "Miller Puckette" msp@ucsd.edu An: "Jaime Oliver" jaime.oliver2@gmail.com Cc: "Christof Ressi" christof.ressi@gmx.at, Pd-list pd-list@lists.iem.at Betreff: Re: [PD] [clone]'s instance number
Cool, taking this suggestion. At least for now it will work either way, but it's much more readable with the abstraction name first so I changed the help file to invoke it that way.
cheers Miller
On Wed, May 11, 2016 at 01:13:37PM -0400, Jaime Oliver wrote:
> Well, > > What would happen if instead of calling clone like: > > [clone 16 my-abstraction 1 5 9] > > we called it with: > > [clone my-abstraction 16 1 5 9] > > and then $1 seems quite appropriate. > > ? > > J > > > > On May 11, 2016, at 12:17 PM, Christof Ressi christof.ressi@gmx.at wrote: >> >> I agree that $1 is most natural! >> >> However, what about adding an additional flag -foo for [clone], which changes the way creation arguments are parsed? >> Passing -foo could ignore the object ID and rather forward creation arguments just as they are. >> >> This wouldn't break the current behaviour of [clone], but provide some functionality to deal with ordinary abstractions more conveniently. >> >> Christof >> >> >> >> >> >> >> >> Gesendet: Mittwoch, 11. Mai 2016 um 18:06 Uhr >> Von: "Ivica Bukvic" ico@vt.edu >> An: "Miller Puckette" msp@ucsd.edu >> Cc: "IOhannes m zmoelnig" zmoelnig@iem.at, Pd-list pd-list@lists.iem.at, "Christof Ressi" christof.ressi@gmx.at >> Betreff: Re: [PD] [clone]'s instance number >> What about >> having an if statement that detects clone object and if so, compensates for $2 discrepancy and assigns $1 to it instead and increments from there? This way the discrepancy is internalized as opposed to something user needs to deal with. >> -- >> Ivica Ico Bukvic, D.M.A. >> Associate Professor >> Computer Music >> ICAT Senior Fellow >> Director -- DISIS, L2Ork >> Virginia Tech >> School of Performing Arts – 0141 >> Blacksburg, VA 24061 >> (540) 231-6139 >> ico@vt.edu >> www.performingarts.vt.edu[http://www.performingarts.vt.edu] >> disis.icat.vt.edu[http://disis.icat.vt.edu] >> l2ork.icat.vt.edu[http://l2ork.icat.vt.edu] >> ico.bukvic.net[http://ico.bukvic.net] >> >> On May 11, 2016 11:50, "Miller Puckette" <msp@ucsd.edu[msp@ucsd.edu]> wrote:I gave this some thought but couldn't come up with anything more natural than >> the "$1" idea. It allows for changing the other arguments more easily than >> it would have been if the instance number were passed last. Also, somehow >> it felt more natural to have the instance number first. >> >> If there's interest in the idea, I could add arrguments to change the >> behavior (such as putting $1 last instead of first)... Offhand I doubt that >> would get used much though. >> >> cheers >> Miller >> >> >> >> On Wed, May 11, 2016 at 05:26:21PM +0200, Christof Ressi wrote: >> >>> 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[zmoelnig@iem.at]> >>>> An: pd-list@lists.iem.at[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[Pd-list@lists.iem.at] mailing list >>>> UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list%5Bhttps://lists.puredata.info/l...] >>>> >>>> >>> ------------------------------ >>> >>> Pd-list@lists.iem.at[Pd-list@lists.iem.at] mailing list >>> UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list%5Bhttps://lists.puredata.info/l...] >>> >> >> ------------------------------ >> >> Pd-list@lists.iem.at[Pd-list@lists.iem.at] mailing list >> UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list%5Bhttps://lists.puredata.info/l...] >> >> ------------------------------ >> >> 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 >
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
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Yep, that's a good point. I think the trouble I'm seeing is that we kind of want two or three levels of locality: the abstraction instance level, the clone bank level, and then patch level. Suppose you use [clone bob] inside an abstraction and have two instances of that abstraction in a parent patch. Inside [clone]'s [bob] instances, $1 will be mapped the same way for each of the two [clone]s, such that [s 1-foo] will be received by [r $1-foo] for the first [bob] instance of each [clone], unless you offset the counting, which means you have to keep track of the counting in parent. Which isn't too onerous, but it is what $0 was designed to avoid in the first place.
On Wed, May 18, 2016 at 12:58 PM, Alex x37v.alex@gmail.com wrote:
So clearly the point is to make it so that abstractions are unaware of being instantiated via [my-abstraction-name 1 2 3] or [clone my-abstraction-name 16 1 2 3]
Inside an abstraction you could have a [r $0-foo] but how do you know $0 outside of the abstraction in either case? My guess is that you'd more often than not use $1 for that [r $1-foo] and clone just works as is without the new flag we're talking about.
I think sending |4 message( into [s foo] shouldn't do any remapping, but I could see some special message going to a clone.
something like:
|send 4 $0-foo message( -> [clone my-abstraction-name 16 1 2 3] (somehow escaping the $0) which would remap the $0 to instance 4's $0 [say its 1021] and then broadcast the message |1021-foo message(
but either way I'm not sure how you'd use the [r $0-foo] from outside the abstraction in the case where you're not using clone..
On Wed, May 18, 2016 at 9:41 AM, Matt Barber brbrofsvl@gmail.com wrote:
I wonder if there's a way to map instance numbers to $0 values in instances. Suppose you had:
[clone -receive foo 16 abstraction 1 2 3]
where 1 2 3 are mapped to $1 $2 $3 inside the instances, respectively.
[clone] makes 16 instances. Then in your abstraction you have [r $0-foo], and [4 <message>(--[s foo] from outside would be received by the [r $0-foo] inside the fourth instance.
The complicated thing here is how to make this work:
[clone -receive $0-foo 16 abstraction 1 2 3]
Since the instances don't know their parent's $0-value, you'd need to modify your abstraction to contain [r $0-$4-foo], and then make [clone -receive $0-foo 16 abstraction 1 2 3 $0]. This is complicated -- probably too complicated -- but the advantage would be that you'd need to make minimal changes to the abstraction. The levels of locality are handled by the user, and it would be much less disruptive to add an extra argument at the end when needed than to get [clone] to try to handle it automatically with the current $1 stuff.
But again, I might be missing something in the design and intended use of the $1 mapping.
On Wed, May 18, 2016 at 10:20 AM, Alex Norman x37v.alex@gmail.com wrote:
I see your point, the abstraction need not know it's instance number since only the messages meant for it would be dispatched to it.. If you don't care about using sends directed to a specific abstraction then the $1 does nothing for you and if the flag to clone could ditch the $1 to instance setting and just set the arguments to the abstraction [clone -flag blah 20 1 2 3] makes 20 copies of blah with args $1=1 $2=2.. You could use more of your existing abstractions as is, using their args the same way with or without clone.
I'm warming up to that idea.
Alex
On May 17, 2016 6:44:51 PM PDT, Christof Ressi christof.ressi@gmx.at wrote:
you can still disambiguate, because incoming messages are dispatched by the instance number and outgoing messages are prepended with it!
My suggestion was mainly concerning all abstractions that work with inlets and outlets (as opposed to sends and receives), where you basically pass a message and get something out. This could be anything, from simple message filtering to a perlin noise generator. Or also existing audio modules that work with a message inlet. If there was such a flag, you could take any of these abstractions as they are, control them separately by prepending the instance number and route the message output (or use the sum of the audio output).
I guess, people will use [clone] mainly for voice management for synthesizers, granular synthesis, complicated nested patches etc., but I also see a great potential for massive data generation by using existing simple abstractions and cloning them.
Personally, I have many abstractions I would like to use with [clone], but either I'd have to rewrite them or make a wrapper abstraction. It's not a big deal, it's just that an alternative forwarding mode would provide some additional convenience (and could also encourage other usages for [clone]).
Anyway, I can totally live without this feature, but would be happy to have it :-).
Gesendet: Mittwoch, 18. Mai 2016 um 02:35 Uhr
Von: "Miller Puckette" msp@ucsd.edu An: "Christof Ressi" christof.ressi@gmx.at Cc: Pd-list pd-list@lists.iem.at Betreff: Re: [PD] [clone]'s instance number
I'm not sure... would anyone ever use this feature? The patch in question would ahve to take arguments (if not, thre's no problem) but not use them to disambiguate the instances (because clone will set them all equal anyway). I have trouble imaginig anyone building a patch like that.
cheers Miller
On Wed, May 18, 2016 at 12:54:16AM +0200, Christof Ressi wrote:
What do you think about the idea with a flag for changing the way creation arguments are forwarded? It would be really handy if you could write something like [clone -flag 100 my-abstraction 5 6 7] and $1 $2 $3 will be substituted by 5 6 7 instead of [N] 5 6. This way you could use existing abstractions as they are, without the need for writing a wrapper abstraction to handle the creation argument forwarding.
Christof
Gesendet: Dienstag, 17. Mai 2016 um 04:05 Uhr > Von: "Miller Puckette" msp@ucsd.edu > An: "Jaime > Oliver" jaime.oliver2@gmail.com > Cc: "Christof Ressi" christof.ressi@gmx.at, Pd-list pd-list@lists.iem.at > Betreff: Re: [PD] [clone]'s instance number > > Cool, taking this suggestion. At least for now it will work either way, > but it's much more readable with the abstraction name first so I changed the > help file to invoke it that way. > > cheers > Miller > > On Wed, May 11, 2016 at 01:13:37PM -0400, Jaime Oliver wrote: > >> Well, >> >> What would happen if instead of calling clone like: >> >> [clone 16 my-abstraction 1 5 9] >> >> we called it with: >> >> [clone my-abstraction 16 1 5 9] >> >> and then $1 seems quite appropriate. >> >> ? >> >> J >> >> >> >> On May 11, 2016, at 12:17 PM, Christof Ressi christof.ressi@gmx.at wrote: >>> >>> I agree that $1 is most natural! >>> >>> However, what about adding an additional flag -foo for [clone], which changes the way creation arguments are parsed? >>> Passing -foo could ignore the object ID and rather forward creation arguments just as they are. >>> >>> This wouldn't break the current behaviour of [clone], but provide some functionality to deal with ordinary abstractions more conveniently. >>> >>> Christof >>> >>> >>> >>> >>> >>> >>> >>> Gesendet: Mittwoch, 11. Mai 2016 um 18:06 Uhr >>> Von: "Ivica Bukvic" ico@vt.edu >>> An: "Miller Puckette" msp@ucsd.edu >>> Cc: "IOhannes m zmoelnig" zmoelnig@iem.at, Pd-list pd-list@lists.iem.at, "Christof Ressi" christof.ressi@gmx.at >>> Betreff: Re: [PD] [clone]'s instance number >>> What about >>> having an if statement that detects clone object and if so, compensates for $2 discrepancy and assigns $1 to it instead and increments from there? This way the discrepancy is internalized as opposed to something user needs to deal with. >>> -- >>> Ivica Ico Bukvic, D.M.A. >>> Associate Professor >>> Computer Music >>> ICAT Senior Fellow >>> Director -- DISIS, L2Ork >>> Virginia Tech >>> School of Performing Arts – 0141 >>> Blacksburg, VA 24061 >>> (540) 231-6139 >>> ico@vt.edu >>> www.performingarts.vt.edu[http://www.performingarts.vt.edu] >>> disis.icat.vt.edu[http://disis.icat.vt.edu] >>> l2ork.icat.vt.edu[http://l2ork.icat.vt.edu] >>> ico.bukvic.net[http://ico.bukvic.net] >>> >>> On May 11, 2016 11:50, "Miller Puckette" <msp@ucsd.edu[msp@ucsd.edu]> wrote:I gave this some thought but couldn't come up with anything more natural than >>> the "$1" idea. It allows for changing the other arguments more easily than >>> it would have been if the instance number were passed last. Also, somehow >>> it felt more natural to have the instance number first. >>> >>> If there's interest in the idea, I could add arrguments to change the >>> behavior (such as putting $1 last instead of first)... Offhand I doubt that >>> would get used much though. >>> >>> cheers >>> Miller >>> >>> >>> >>> On Wed, May 11, 2016 at 05:26:21PM +0200, Christof Ressi wrote: >>> >>>> 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[zmoelnig@iem.at]> >>>>> An: pd-list@lists.iem.at[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[Pd-list@lists.iem.at] mailing list >>>>> UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list%5Bhttps://lists.puredata.info/l...] >>>>> >>>>> >>>> ------------------------------ >>>> >>>> Pd-list@lists.iem.at[Pd-list@lists.iem.at] mailing list >>>> UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list%5Bhttps://lists.puredata.info/l...] >>>> >>> >>> ------------------------------ >>> >>> Pd-list@lists.iem.at[Pd-list@lists.iem.at] mailing list >>> UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list%5Bhttps://lists.puredata.info/l...] >>> >>> ------------------------------ >>> >>> 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 >> >
>
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
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
OK... sounds like it's worth putting in. I guess with the one-letter it already takes (-s) I should also add something like a -e flag to put the number argument at the end of the list instead of the beginning, or something like that.
cheers Miller
On Wed, May 18, 2016 at 07:20:29AM -0700, Alex Norman wrote:
I see your point, the abstraction need not know it's instance number since only the messages meant for it would be dispatched to it.. If you don't care about using sends directed to a specific abstraction then the $1 does nothing for you and if the flag to clone could ditch the $1 to instance setting and just set the arguments to the abstraction [clone -flag blah 20 1 2 3] makes 20 copies of blah with args $1=1 $2=2.. You could use more of your existing abstractions as is, using their args the same way with or without clone.
I'm warming up to that idea.
Alex
On May 17, 2016 6:44:51 PM PDT, Christof Ressi christof.ressi@gmx.at wrote:
you can still disambiguate, because incoming messages are dispatched by the instance number and outgoing messages are prepended with it!
My suggestion was mainly concerning all abstractions that work with inlets and outlets (as opposed to sends and receives), where you basically pass a message and get something out. This could be anything, from simple message filtering to a perlin noise generator. Or also existing audio modules that work with a message inlet. If there was such a flag, you could take any of these abstractions as they are, control them separately by prepending the instance number and route the message output (or use the sum of the audio output).
I guess, people will use [clone] mainly for voice management for synthesizers, granular synthesis, complicated nested patches etc., but I also see a great potential for massive data generation by using existing simple abstractions and cloning them.
Personally, I have many abstractions I would like to use with [clone], but either I'd have to rewrite them or make a wrapper abstraction. It's not a big deal, it's just that an alternative forwarding mode would provide some additional convenience (and could also encourage other usages for [clone]).
Anyway, I can totally live without this feature, but would be happy to have it :-).
Gesendet: Mittwoch, 18. Mai 2016 um 02:35 Uhr Von: "Miller Puckette" msp@ucsd.edu An: "Christof Ressi" christof.ressi@gmx.at Cc: Pd-list pd-list@lists.iem.at Betreff: Re: [PD] [clone]'s instance number
I'm not sure... would anyone ever use this feature? The patch in
question
would ahve to take arguments (if not, thre's no problem) but not use
them to
disambiguate the instances (because clone will set them all equal
anyway).
I have trouble imaginig anyone building a patch like that.
cheers Miller
On Wed, May 18, 2016 at 12:54:16AM +0200, Christof Ressi wrote:
What do you think about the idea with a flag for changing the way
creation arguments are forwarded? It would be really handy if you could write something like
[clone -flag 100 my-abstraction 5 6 7] and $1 $2 $3 will be
substituted by 5 6 7 instead of [N] 5 6. This way you could use existing abstractions as they are, without the need for writing a wrapper abstraction to handle the creation argument forwarding.
Christof
Gesendet: Dienstag, 17. Mai 2016 um 04:05 Uhr Von: "Miller Puckette" msp@ucsd.edu An: "Jaime Oliver" jaime.oliver2@gmail.com Cc: "Christof Ressi" christof.ressi@gmx.at, Pd-list
Betreff: Re: [PD] [clone]'s instance number
Cool, taking this suggestion. At least for now it will work
either way,
but it's much more readable with the abstraction name first so I
changed the
help file to invoke it that way.
cheers Miller
On Wed, May 11, 2016 at 01:13:37PM -0400, Jaime Oliver wrote:
Well,
What would happen if instead of calling clone like:
[clone 16 my-abstraction 1 5 9]
we called it with:
[clone my-abstraction 16 1 5 9]
and then $1 seems quite appropriate.
?
J
> On May 11, 2016, at 12:17 PM, Christof Ressi
christof.ressi@gmx.at wrote:
> > I agree that $1 is most natural! > > However, what about adding an additional flag -foo for
[clone], which changes the way creation arguments are parsed?
> Passing -foo could ignore the object ID and rather forward
creation arguments just as they are.
> > This wouldn't break the current behaviour of [clone], but
provide some functionality to deal with ordinary abstractions more conveniently.
> > Christof > > > > >
>
> > Gesendet: Mittwoch, 11. Mai 2016 um 18:06 Uhr > Von: "Ivica Bukvic" ico@vt.edu > An: "Miller Puckette" msp@ucsd.edu > Cc: "IOhannes m zmoelnig" zmoelnig@iem.at, Pd-listpd-list@lists.iem.at, "Christof Ressi" christof.ressi@gmx.at
> Betreff: Re: [PD] [clone]'s instance number > What about having an if statement that detects clone object
and if so, compensates for $2 discrepancy and assigns $1 to it instead and increments from there? This way the discrepancy is internalized as opposed to something user needs to deal with.
> -- > Ivica Ico Bukvic, D.M.A. > Associate Professor > Computer Music > ICAT Senior Fellow > Director -- DISIS, L2Ork > Virginia Tech > School of Performing Arts – 0141 > Blacksburg, VA 24061 > (540) 231-6139 > ico@vt.edu > www.performingarts.vt.edu[http://www.performingarts.vt.edu] > disis.icat.vt.edu[http://disis.icat.vt.edu] > l2ork.icat.vt.edu[http://l2ork.icat.vt.edu] > ico.bukvic.net[http://ico.bukvic.net] > > On May 11, 2016 11:50, "Miller Puckette"
<msp@ucsd.edu[msp@ucsd.edu]> wrote:I gave this some thought but couldn't come up with anything more natural than
> the "$1" idea. It allows for changing the other arguments
more easily than
> it would have been if the instance number were passed last.
Also, somehow
> it felt more natural to have the instance number first. > > If there's interest in the idea, I could add arrguments to
change the
> behavior (such as putting $1 last instead of first)...
Offhand I doubt that
> would get used much though. > > cheers > Miller > > > > On Wed, May 11, 2016 at 05:26:21PM +0200, Christof Ressi
wrote:
>> 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[zmoelnig@iem.at]>
>>> An: pd-list@lists.iem.at[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[Pd-list@lists.iem.at] mailing list >>> UNSUBSCRIBE and account-management ->
https://lists.puredata.info/listinfo/pd-list%5Bhttps://lists.puredata.info/l...]
>>> >> >> _______________________________________________ >> Pd-list@lists.iem.at[Pd-list@lists.iem.at] mailing list >> UNSUBSCRIBE and account-management ->
https://lists.puredata.info/listinfo/pd-list%5Bhttps://lists.puredata.info/l...]
> > _______________________________________________ > Pd-list@lists.iem.at[Pd-list@lists.iem.at] mailing list > UNSUBSCRIBE and account-management ->
https://lists.puredata.info/listinfo/pd-list%5Bhttps://lists.puredata.info/l...]
> > _______________________________________________ > 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
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
If I am understanding correctly the alternative mode, the idea is not so much to put it at the end or at the beginning, but to have a routing mechanism incorporated so that if you send the message
1 2 3
to clone,
then instance 1 gets the message 2 3 in its inlet.
right?
In the mode where $1 is the instance number this would be done by putting in the abstraction
[inlet] | [route $1]
Then the outlet would prepend the instance number?
How would this all be managed with audio? Are we making it unnecessarily complex?
J
On May 18, 2016, at 12:45 PM, Miller Puckette msp@ucsd.edu wrote:
OK... sounds like it's worth putting in. I guess with the one-letter it already takes (-s) I should also add something like a -e flag to put the number argument at the end of the list instead of the beginning, or something like that.
cheers Miller
On Wed, May 18, 2016 at 07:20:29AM -0700, Alex Norman wrote:
I see your point, the abstraction need not know it's instance number since only the messages meant for it would be dispatched to it.. If you don't care about using sends directed to a specific abstraction then the $1 does nothing for you and if the flag to clone could ditch the $1 to instance setting and just set the arguments to the abstraction [clone -flag blah 20 1 2 3] makes 20 copies of blah with args $1=1 $2=2.. You could use more of your existing abstractions as is, using their args the same way with or without clone.
I'm warming up to that idea.
Alex
On May 17, 2016 6:44:51 PM PDT, Christof Ressi christof.ressi@gmx.at wrote:
you can still disambiguate, because incoming messages are dispatched by the instance number and outgoing messages are prepended with it!
My suggestion was mainly concerning all abstractions that work with inlets and outlets (as opposed to sends and receives), where you basically pass a message and get something out. This could be anything, from simple message filtering to a perlin noise generator. Or also existing audio modules that work with a message inlet. If there was such a flag, you could take any of these abstractions as they are, control them separately by prepending the instance number and route the message output (or use the sum of the audio output).
I guess, people will use [clone] mainly for voice management for synthesizers, granular synthesis, complicated nested patches etc., but I also see a great potential for massive data generation by using existing simple abstractions and cloning them.
Personally, I have many abstractions I would like to use with [clone], but either I'd have to rewrite them or make a wrapper abstraction. It's not a big deal, it's just that an alternative forwarding mode would provide some additional convenience (and could also encourage other usages for [clone]).
Anyway, I can totally live without this feature, but would be happy to have it :-).
Gesendet: Mittwoch, 18. Mai 2016 um 02:35 Uhr Von: "Miller Puckette" msp@ucsd.edu An: "Christof Ressi" christof.ressi@gmx.at Cc: Pd-list pd-list@lists.iem.at Betreff: Re: [PD] [clone]'s instance number
I'm not sure... would anyone ever use this feature? The patch in
question
would ahve to take arguments (if not, thre's no problem) but not use
them to
disambiguate the instances (because clone will set them all equal
anyway).
I have trouble imaginig anyone building a patch like that.
cheers Miller
On Wed, May 18, 2016 at 12:54:16AM +0200, Christof Ressi wrote:
What do you think about the idea with a flag for changing the way
creation arguments are forwarded? It would be really handy if you could write something like
[clone -flag 100 my-abstraction 5 6 7] and $1 $2 $3 will be
substituted by 5 6 7 instead of [N] 5 6. This way you could use existing abstractions as they are, without the need for writing a wrapper abstraction to handle the creation argument forwarding.
Christof
Gesendet: Dienstag, 17. Mai 2016 um 04:05 Uhr Von: "Miller Puckette" msp@ucsd.edu An: "Jaime Oliver" jaime.oliver2@gmail.com Cc: "Christof Ressi" christof.ressi@gmx.at, Pd-list
Betreff: Re: [PD] [clone]'s instance number
Cool, taking this suggestion. At least for now it will work
either way,
but it's much more readable with the abstraction name first so I
changed the
help file to invoke it that way.
cheers Miller
On Wed, May 11, 2016 at 01:13:37PM -0400, Jaime Oliver wrote: > Well, > > What would happen if instead of calling clone like: > > [clone 16 my-abstraction 1 5 9] > > we called it with: > > [clone my-abstraction 16 1 5 9] > > and then $1 seems quite appropriate. > > ? > > J > > > >> On May 11, 2016, at 12:17 PM, Christof Ressi
christof.ressi@gmx.at wrote:
>> >> I agree that $1 is most natural! >> >> However, what about adding an additional flag -foo for
[clone], which changes the way creation arguments are parsed?
>> Passing -foo could ignore the object ID and rather forward
creation arguments just as they are.
>> >> This wouldn't break the current behaviour of [clone], but
provide some functionality to deal with ordinary abstractions more conveniently.
>> >> Christof >> >> >> >> >> >> >> >> Gesendet: Mittwoch, 11. Mai 2016 um 18:06 Uhr >> Von: "Ivica Bukvic" ico@vt.edu >> An: "Miller Puckette" msp@ucsd.edu >> Cc: "IOhannes m zmoelnig" zmoelnig@iem.at, Pd-list
pd-list@lists.iem.at, "Christof Ressi" christof.ressi@gmx.at
>> Betreff: Re: [PD] [clone]'s instance number >> What about having an if statement that detects clone object
and if so, compensates for $2 discrepancy and assigns $1 to it instead and increments from there? This way the discrepancy is internalized as opposed to something user needs to deal with.
>> -- >> Ivica Ico Bukvic, D.M.A. >> Associate Professor >> Computer Music >> ICAT Senior Fellow >> Director -- DISIS, L2Ork >> Virginia Tech >> School of Performing Arts – 0141 >> Blacksburg, VA 24061 >> (540) 231-6139 >> ico@vt.edu >> www.performingarts.vt.edu[http://www.performingarts.vt.edu] >> disis.icat.vt.edu[http://disis.icat.vt.edu] >> l2ork.icat.vt.edu[http://l2ork.icat.vt.edu] >> ico.bukvic.net[http://ico.bukvic.net] >> >> On May 11, 2016 11:50, "Miller Puckette"
<msp@ucsd.edu[msp@ucsd.edu]> wrote:I gave this some thought but couldn't come up with anything more natural than
>> the "$1" idea. It allows for changing the other arguments
more easily than
>> it would have been if the instance number were passed last.
Also, somehow
>> it felt more natural to have the instance number first. >> >> If there's interest in the idea, I could add arrguments to
change the
>> behavior (such as putting $1 last instead of first)...
Offhand I doubt that
>> would get used much though. >> >> cheers >> Miller >> >> >> >> On Wed, May 11, 2016 at 05:26:21PM +0200, Christof Ressi
wrote:
>>> 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[zmoelnig@iem.at]>
>>>> An: pd-list@lists.iem.at[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[Pd-list@lists.iem.at] mailing list >>>> UNSUBSCRIBE and account-management ->
https://lists.puredata.info/listinfo/pd-list%5Bhttps://lists.puredata.info/l...]
>>>> >>> >>> _______________________________________________ >>> Pd-list@lists.iem.at[Pd-list@lists.iem.at] mailing list >>> UNSUBSCRIBE and account-management ->
https://lists.puredata.info/listinfo/pd-list%5Bhttps://lists.puredata.info/l...]
>> >> _______________________________________________ >> Pd-list@lists.iem.at[Pd-list@lists.iem.at] mailing list >> UNSUBSCRIBE and account-management ->
https://lists.puredata.info/listinfo/pd-list%5Bhttps://lists.puredata.info/l...]
>> >> _______________________________________________ >> 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
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
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
I believe that in any mode, as is, sending the message |1 2 3( to the nth input of [clone blah 16] object will route the message |2 3( to instance 1's nth input. At this point I think all audio sent via [inlet~] or [outlet~] is summed.
As is, I think its a pretty nice approach and something I've been wanting in PD for a long time.
On Wed, May 18, 2016 at 10:08 AM, Jaime Oliver jaime.oliver2@gmail.com wrote:
If I am understanding correctly the alternative mode, the idea is not so much to put it at the end or at the beginning, but to have a routing mechanism incorporated so that if you send the message
1 2 3
to clone,
then instance 1 gets the message 2 3 in its inlet.
right?
In the mode where $1 is the instance number this would be done by putting in the abstraction
[inlet] | [route $1]
Then the outlet would prepend the instance number?
How would this all be managed with audio? Are we making it unnecessarily complex?
J
On May 18, 2016, at 12:45 PM, Miller Puckette msp@ucsd.edu wrote:
OK... sounds like it's worth putting in. I guess with the one-letter it already takes (-s) I should also add something like a -e flag to put the number argument at the end of the list instead of the beginning, or
something
like that.
cheers Miller
On Wed, May 18, 2016 at 07:20:29AM -0700, Alex Norman wrote:
I see your point, the abstraction need not know it's instance number
since only the messages meant for it would be dispatched to it.. If you don't care about using sends directed to a specific abstraction then the $1 does nothing for you and if the flag to clone could ditch the $1 to instance setting and just set the arguments to the abstraction [clone -flag blah 20 1 2 3] makes 20 copies of blah with args $1=1 $2=2.. You could use more of your existing abstractions as is, using their args the same way with or without clone.
I'm warming up to that idea.
Alex
On May 17, 2016 6:44:51 PM PDT, Christof Ressi christof.ressi@gmx.at
wrote:
you can still disambiguate, because incoming messages are dispatched by the instance number and outgoing messages are prepended with it!
My suggestion was mainly concerning all abstractions that work with inlets and outlets (as opposed to sends and receives), where you basically pass a message and get something out. This could be anything, from simple message filtering to a perlin noise generator. Or also existing audio modules that work with a message inlet. If there was such a flag, you could take any of these abstractions as they are, control them separately by prepending the instance number and route the message output (or use the sum of the audio output).
I guess, people will use [clone] mainly for voice management for synthesizers, granular synthesis, complicated nested patches etc., but I also see a great potential for massive data generation by using existing simple abstractions and cloning them.
Personally, I have many abstractions I would like to use with [clone], but either I'd have to rewrite them or make a wrapper abstraction. It's not a big deal, it's just that an alternative forwarding mode would provide some additional convenience (and could also encourage other usages for [clone]).
Anyway, I can totally live without this feature, but would be happy to have it :-).
Gesendet: Mittwoch, 18. Mai 2016 um 02:35 Uhr Von: "Miller Puckette" msp@ucsd.edu An: "Christof Ressi" christof.ressi@gmx.at Cc: Pd-list pd-list@lists.iem.at Betreff: Re: [PD] [clone]'s instance number
I'm not sure... would anyone ever use this feature? The patch in
question
would ahve to take arguments (if not, thre's no problem) but not use
them to
disambiguate the instances (because clone will set them all equal
anyway).
I have trouble imaginig anyone building a patch like that.
cheers Miller
On Wed, May 18, 2016 at 12:54:16AM +0200, Christof Ressi wrote:
What do you think about the idea with a flag for changing the way
creation arguments are forwarded? It would be really handy if you could write something like
[clone -flag 100 my-abstraction 5 6 7] and $1 $2 $3 will be
substituted by 5 6 7 instead of [N] 5 6. This way you could use existing abstractions as they are, without the need for writing a wrapper abstraction to handle the creation argument forwarding.
Christof
> Gesendet: Dienstag, 17. Mai 2016 um 04:05 Uhr > Von: "Miller Puckette" msp@ucsd.edu > An: "Jaime Oliver" jaime.oliver2@gmail.com > Cc: "Christof Ressi" christof.ressi@gmx.at, Pd-list
> Betreff: Re: [PD] [clone]'s instance number > > Cool, taking this suggestion. At least for now it will work
either way,
> but it's much more readable with the abstraction name first so I
changed the
> help file to invoke it that way. > > cheers > Miller > > On Wed, May 11, 2016 at 01:13:37PM -0400, Jaime Oliver wrote: >> Well, >> >> What would happen if instead of calling clone like: >> >> [clone 16 my-abstraction 1 5 9] >> >> we called it with: >> >> [clone my-abstraction 16 1 5 9] >> >> and then $1 seems quite appropriate. >> >> ? >> >> J >> >> >> >>> On May 11, 2016, at 12:17 PM, Christof Ressi
christof.ressi@gmx.at wrote:
>>> >>> I agree that $1 is most natural! >>> >>> However, what about adding an additional flag -foo for
[clone], which changes the way creation arguments are parsed?
>>> Passing -foo could ignore the object ID and rather forward
creation arguments just as they are.
>>> >>> This wouldn't break the current behaviour of [clone], but
provide some functionality to deal with ordinary abstractions more conveniently.
>>> >>> Christof >>> >>> >>> >>> >>> >>> >>> >>> Gesendet: Mittwoch, 11. Mai 2016 um 18:06 Uhr >>> Von: "Ivica Bukvic" ico@vt.edu >>> An: "Miller Puckette" msp@ucsd.edu >>> Cc: "IOhannes m zmoelnig" zmoelnig@iem.at, Pd-list
pd-list@lists.iem.at, "Christof Ressi" christof.ressi@gmx.at
>>> Betreff: Re: [PD] [clone]'s instance number >>> What about having an if statement that detects clone object
and if so, compensates for $2 discrepancy and assigns $1 to it instead and increments from there? This way the discrepancy is internalized as opposed to something user needs to deal with.
>>> -- >>> Ivica Ico Bukvic, D.M.A. >>> Associate Professor >>> Computer Music >>> ICAT Senior Fellow >>> Director -- DISIS, L2Ork >>> Virginia Tech >>> School of Performing Arts – 0141 >>> Blacksburg, VA 24061 >>> (540) 231-6139 >>> ico@vt.edu >>> www.performingarts.vt.edu[http://www.performingarts.vt.edu] >>> disis.icat.vt.edu[http://disis.icat.vt.edu] >>> l2ork.icat.vt.edu[http://l2ork.icat.vt.edu] >>> ico.bukvic.net[http://ico.bukvic.net] >>> >>> On May 11, 2016 11:50, "Miller Puckette"
<msp@ucsd.edu[msp@ucsd.edu]> wrote:I gave this some thought but couldn't come up with anything more natural than
>>> the "$1" idea. It allows for changing the other arguments
more easily than
>>> it would have been if the instance number were passed last.
Also, somehow
>>> it felt more natural to have the instance number first. >>> >>> If there's interest in the idea, I could add arrguments to
change the
>>> behavior (such as putting $1 last instead of first)...
Offhand I doubt that
>>> would get used much though. >>> >>> cheers >>> Miller >>> >>> >>> >>> On Wed, May 11, 2016 at 05:26:21PM +0200, Christof Ressi
wrote:
>>>> 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[zmoelnig@iem.at]>
>>>>> An: pd-list@lists.iem.at[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[Pd-list@lists.iem.at] mailing list >>>>> UNSUBSCRIBE and account-management ->
https://lists.puredata.info/listinfo/pd-list%5Bhttps://lists.puredata.info/l...]
>>>>> >>>> >>>> _______________________________________________ >>>> Pd-list@lists.iem.at[Pd-list@lists.iem.at] mailing list >>>> UNSUBSCRIBE and account-management ->
https://lists.puredata.info/listinfo/pd-list%5Bhttps://lists.puredata.info/l...]
>>> >>> _______________________________________________ >>> Pd-list@lists.iem.at[Pd-list@lists.iem.at] mailing list >>> UNSUBSCRIBE and account-management ->
https://lists.puredata.info/listinfo/pd-list%5Bhttps://lists.puredata.info/l...]
>>> >>> _______________________________________________ >>> 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
>
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
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management ->
As is, I think its a pretty nice approach and something I've been wanting in PD for a long time.
Agree… J
On Wed, May 18, 2016 at 10:08 AM, Jaime Oliver <jaime.oliver2@gmail.com mailto:jaime.oliver2@gmail.com> wrote: If I am understanding correctly the alternative mode, the idea is not so much to put it at the end or at the beginning, but to have a routing mechanism incorporated so that if you send the message
1 2 3
to clone,
then instance 1 gets the message 2 3 in its inlet.
right?
In the mode where $1 is the instance number this would be done by putting in the abstraction
[inlet] | [route $1]
Then the outlet would prepend the instance number?
How would this all be managed with audio? Are we making it unnecessarily complex?
J
On May 18, 2016, at 12:45 PM, Miller Puckette <msp@ucsd.edu mailto:msp@ucsd.edu> wrote:
OK... sounds like it's worth putting in. I guess with the one-letter it already takes (-s) I should also add something like a -e flag to put the number argument at the end of the list instead of the beginning, or something like that.
cheers Miller
On Wed, May 18, 2016 at 07:20:29AM -0700, Alex Norman wrote:
I see your point, the abstraction need not know it's instance number since only the messages meant for it would be dispatched to it.. If you don't care about using sends directed to a specific abstraction then the $1 does nothing for you and if the flag to clone could ditch the $1 to instance setting and just set the arguments to the abstraction [clone -flag blah 20 1 2 3] makes 20 copies of blah with args $1=1 $2=2.. You could use more of your existing abstractions as is, using their args the same way with or without clone.
I'm warming up to that idea.
Alex
On May 17, 2016 6:44:51 PM PDT, Christof Ressi <christof.ressi@gmx.at mailto:christof.ressi@gmx.at> wrote:
you can still disambiguate, because incoming messages are dispatched by the instance number and outgoing messages are prepended with it!
My suggestion was mainly concerning all abstractions that work with inlets and outlets (as opposed to sends and receives), where you basically pass a message and get something out. This could be anything, from simple message filtering to a perlin noise generator. Or also existing audio modules that work with a message inlet. If there was such a flag, you could take any of these abstractions as they are, control them separately by prepending the instance number and route the message output (or use the sum of the audio output).
I guess, people will use [clone] mainly for voice management for synthesizers, granular synthesis, complicated nested patches etc., but I also see a great potential for massive data generation by using existing simple abstractions and cloning them.
Personally, I have many abstractions I would like to use with [clone], but either I'd have to rewrite them or make a wrapper abstraction. It's not a big deal, it's just that an alternative forwarding mode would provide some additional convenience (and could also encourage other usages for [clone]).
Anyway, I can totally live without this feature, but would be happy to have it :-).
Gesendet: Mittwoch, 18. Mai 2016 um 02:35 Uhr Von: "Miller Puckette" <msp@ucsd.edu mailto:msp@ucsd.edu> An: "Christof Ressi" <christof.ressi@gmx.at mailto:christof.ressi@gmx.at> Cc: Pd-list <pd-list@lists.iem.at mailto:pd-list@lists.iem.at> Betreff: Re: [PD] [clone]'s instance number
I'm not sure... would anyone ever use this feature? The patch in
question
would ahve to take arguments (if not, thre's no problem) but not use
them to
disambiguate the instances (because clone will set them all equal
anyway).
I have trouble imaginig anyone building a patch like that.
cheers Miller
On Wed, May 18, 2016 at 12:54:16AM +0200, Christof Ressi wrote:
What do you think about the idea with a flag for changing the way
creation arguments are forwarded? It would be really handy if you could write something like
[clone -flag 100 my-abstraction 5 6 7] and $1 $2 $3 will be
substituted by 5 6 7 instead of [N] 5 6. This way you could use existing abstractions as they are, without the need for writing a wrapper abstraction to handle the creation argument forwarding.
Christof
> Gesendet: Dienstag, 17. Mai 2016 um 04:05 Uhr > Von: "Miller Puckette" <msp@ucsd.edu mailto:msp@ucsd.edu> > An: "Jaime Oliver" <jaime.oliver2@gmail.com mailto:jaime.oliver2@gmail.com> > Cc: "Christof Ressi" <christof.ressi@gmx.at mailto:christof.ressi@gmx.at>, Pd-list
<pd-list@lists.iem.at mailto:pd-list@lists.iem.at>
> Betreff: Re: [PD] [clone]'s instance number > > Cool, taking this suggestion. At least for now it will work
either way,
> but it's much more readable with the abstraction name first so I
changed the
> help file to invoke it that way. > > cheers > Miller > > On Wed, May 11, 2016 at 01:13:37PM -0400, Jaime Oliver wrote: >> Well, >> >> What would happen if instead of calling clone like: >> >> [clone 16 my-abstraction 1 5 9] >> >> we called it with: >> >> [clone my-abstraction 16 1 5 9] >> >> and then $1 seems quite appropriate. >> >> ? >> >> J >> >> >> >>> On May 11, 2016, at 12:17 PM, Christof Ressi
<christof.ressi@gmx.at mailto:christof.ressi@gmx.at> wrote:
>>> >>> I agree that $1 is most natural! >>> >>> However, what about adding an additional flag -foo for
[clone], which changes the way creation arguments are parsed?
>>> Passing -foo could ignore the object ID and rather forward
creation arguments just as they are.
>>> >>> This wouldn't break the current behaviour of [clone], but
provide some functionality to deal with ordinary abstractions more conveniently.
>>> >>> Christof >>> >>> >>> >>> >>> >>> >>> >>> Gesendet: Mittwoch, 11. Mai 2016 um 18:06 Uhr >>> Von: "Ivica Bukvic" <ico@vt.edu mailto:ico@vt.edu> >>> An: "Miller Puckette" <msp@ucsd.edu mailto:msp@ucsd.edu> >>> Cc: "IOhannes m zmoelnig" <zmoelnig@iem.at mailto:zmoelnig@iem.at>, Pd-list
<pd-list@lists.iem.at mailto:pd-list@lists.iem.at>, "Christof Ressi" <christof.ressi@gmx.at mailto:christof.ressi@gmx.at>
>>> Betreff: Re: [PD] [clone]'s instance number >>> What about having an if statement that detects clone object
and if so, compensates for $2 discrepancy and assigns $1 to it instead and increments from there? This way the discrepancy is internalized as opposed to something user needs to deal with.
>>> -- >>> Ivica Ico Bukvic, D.M.A. >>> Associate Professor >>> Computer Music >>> ICAT Senior Fellow >>> Director -- DISIS, L2Ork >>> Virginia Tech >>> School of Performing Arts – 0141 >>> Blacksburg, VA 24061 >>> (540) 231-6139 tel:%28540%29%20231-6139 >>> ico@vt.edu mailto:ico@vt.edu >>> www.performingarts.vt.edu http://www.performingarts.vt.edu/[http://www.performingarts.vt.edu http://www.performingarts.vt.edu/] >>> disis.icat.vt.edu http://disis.icat.vt.edu/[http://disis.icat.vt.edu http://disis.icat.vt.edu/] >>> l2ork.icat.vt.edu http://l2ork.icat.vt.edu/[http://l2ork.icat.vt.edu http://l2ork.icat.vt.edu/] >>> ico.bukvic.net http://ico.bukvic.net/[http://ico.bukvic.net http://ico.bukvic.net/] >>> >>> On May 11, 2016 11:50, "Miller Puckette"
<msp@ucsd.edu mailto:msp@ucsd.edu[msp@ucsd.edu mailto:msp@ucsd.edu]> wrote:I gave this some thought but couldn't come up with anything more natural than
>>> the "$1" idea. It allows for changing the other arguments
more easily than
>>> it would have been if the instance number were passed last.
Also, somehow
>>> it felt more natural to have the instance number first. >>> >>> If there's interest in the idea, I could add arrguments to
change the
>>> behavior (such as putting $1 last instead of first)...
Offhand I doubt that
>>> would get used much though. >>> >>> cheers >>> Miller >>> >>> >>> >>> On Wed, May 11, 2016 at 05:26:21PM +0200, Christof Ressi
wrote:
>>>> 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 mailto:zmoelnig@iem.at[zmoelnig@iem.at mailto:zmoelnig@iem.at]>
>>>>> An: pd-list@lists.iem.at mailto:pd-list@lists.iem.at[pd-list@lists.iem.at mailto: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 mailto:Pd-list@lists.iem.at[Pd-list@lists.iem.at mailto:Pd-list@lists.iem.at] mailing list >>>>> UNSUBSCRIBE and account-management ->
https://lists.puredata.info/listinfo/pd-list%5Bhttps://lists.puredata.info/l...] https://lists.puredata.info/listinfo/pd-list[https://lists.puredata.info/listinfo/pd-list]
>>>>> >>>> >>>> _______________________________________________ >>>> Pd-list@lists.iem.at mailto:Pd-list@lists.iem.at[Pd-list@lists.iem.at mailto:Pd-list@lists.iem.at] mailing list >>>> UNSUBSCRIBE and account-management ->
https://lists.puredata.info/listinfo/pd-list%5Bhttps://lists.puredata.info/l...] https://lists.puredata.info/listinfo/pd-list[https://lists.puredata.info/listinfo/pd-list]
>>> >>> _______________________________________________ >>> Pd-list@lists.iem.at mailto:Pd-list@lists.iem.at[Pd-list@lists.iem.at mailto:Pd-list@lists.iem.at] mailing list >>> UNSUBSCRIBE and account-management ->
https://lists.puredata.info/listinfo/pd-list%5Bhttps://lists.puredata.info/l...] https://lists.puredata.info/listinfo/pd-list[https://lists.puredata.info/listinfo/pd-list]
>>> >>> _______________________________________________ >>> Pd-list@lists.iem.at mailto:Pd-list@lists.iem.at mailing list >>> UNSUBSCRIBE and account-management ->
https://lists.puredata.info/listinfo/pd-list https://lists.puredata.info/listinfo/pd-list
>> >> >> _______________________________________________ >> Pd-list@lists.iem.at mailto:Pd-list@lists.iem.at mailing list >> UNSUBSCRIBE and account-management ->
https://lists.puredata.info/listinfo/pd-list https://lists.puredata.info/listinfo/pd-list
>
Pd-list@lists.iem.at mailto:Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management ->
https://lists.puredata.info/listinfo/pd-list https://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailto:Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list https://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailto:Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list https://lists.puredata.info/listinfo/pd-list
I should also add something like a -e flag to put the number argument at the end of the list instead of the beginning, or something like that.
Putting it at the end of the list can be dangerous in the following case: Let's say your abstraction takes max. 5 creation arguments, but in clone you called it with only 2 of them (relying on some default value mechanism inside your abstraction for the missing arguments). Having the instance number at the end of your creation argument list will mess up with the third creation argument. So you'd always have to call an abstraction by all their creation arguments to prevent the instance number sneaking its way in.
Since my proposed alternative mode is mainly about abstractions which don't care about any instance numbers themselves (and were maybe written before the advent of [clone]), I guess it's best to just skip the instance number entirely for this mode to avoid any possible suprises. If one wanted to use the instance number, they would design their abstraction accordingly (and probably use the 'main' mode).
BTW: I guess, it's mostly a design question, whether to work with instance numbers inside abstractions and or to work with dispatching via the inlets and outlets. However, I can think of at least two cases where it's necessary to have immediate access to instance numbers inside an abstraction: a) [send~ foo-$1] or [catch~ bar-$1] to disambiguate audio inputs/outputs, because you can't set these two dynamically like [r~] and [throw~] b) instantiate another abstraction by the instance number (nested abstractions)
So the current behaviour of [clone] (passing the instance number as $1) can be important and very useful. The alternative mode I proposed is mainly for convenience but I'm sure it would pay off in the long run!
Gesendet: Mittwoch, 18. Mai 2016 um 18:45 Uhr Von: "Miller Puckette" msp@ucsd.edu An: "Alex Norman" x37v.alex@gmail.com Cc: "Christof Ressi" christof.ressi@gmx.at, Pd-list pd-list@lists.iem.at Betreff: Re: [PD] [clone]'s instance number
OK... sounds like it's worth putting in. I guess with the one-letter it already takes (-s) I should also add something like a -e flag to put the number argument at the end of the list instead of the beginning, or something like that.
cheers Miller
On Wed, May 18, 2016 at 07:20:29AM -0700, Alex Norman wrote:
I see your point, the abstraction need not know it's instance number since only the messages meant for it would be dispatched to it.. If you don't care about using sends directed to a specific abstraction then the $1 does nothing for you and if the flag to clone could ditch the $1 to instance setting and just set the arguments to the abstraction [clone -flag blah 20 1 2 3] makes 20 copies of blah with args $1=1 $2=2.. You could use more of your existing abstractions as is, using their args the same way with or without clone.
I'm warming up to that idea.
Alex
On May 17, 2016 6:44:51 PM PDT, Christof Ressi christof.ressi@gmx.at wrote:
you can still disambiguate, because incoming messages are dispatched by the instance number and outgoing messages are prepended with it!
My suggestion was mainly concerning all abstractions that work with inlets and outlets (as opposed to sends and receives), where you basically pass a message and get something out. This could be anything, from simple message filtering to a perlin noise generator. Or also existing audio modules that work with a message inlet. If there was such a flag, you could take any of these abstractions as they are, control them separately by prepending the instance number and route the message output (or use the sum of the audio output).
I guess, people will use [clone] mainly for voice management for synthesizers, granular synthesis, complicated nested patches etc., but I also see a great potential for massive data generation by using existing simple abstractions and cloning them.
Personally, I have many abstractions I would like to use with [clone], but either I'd have to rewrite them or make a wrapper abstraction. It's not a big deal, it's just that an alternative forwarding mode would provide some additional convenience (and could also encourage other usages for [clone]).
Anyway, I can totally live without this feature, but would be happy to have it :-).
Gesendet: Mittwoch, 18. Mai 2016 um 02:35 Uhr Von: "Miller Puckette" msp@ucsd.edu An: "Christof Ressi" christof.ressi@gmx.at Cc: Pd-list pd-list@lists.iem.at Betreff: Re: [PD] [clone]'s instance number
I'm not sure... would anyone ever use this feature? The patch in
question
would ahve to take arguments (if not, thre's no problem) but not use
them to
disambiguate the instances (because clone will set them all equal
anyway).
I have trouble imaginig anyone building a patch like that.
cheers Miller
On Wed, May 18, 2016 at 12:54:16AM +0200, Christof Ressi wrote:
What do you think about the idea with a flag for changing the way
creation arguments are forwarded? It would be really handy if you could write something like
[clone -flag 100 my-abstraction 5 6 7] and $1 $2 $3 will be
substituted by 5 6 7 instead of [N] 5 6. This way you could use existing abstractions as they are, without the need for writing a wrapper abstraction to handle the creation argument forwarding.
Christof
Gesendet: Dienstag, 17. Mai 2016 um 04:05 Uhr Von: "Miller Puckette" msp@ucsd.edu An: "Jaime Oliver" jaime.oliver2@gmail.com Cc: "Christof Ressi" christof.ressi@gmx.at, Pd-list
Betreff: Re: [PD] [clone]'s instance number
Cool, taking this suggestion. At least for now it will work
either way,
but it's much more readable with the abstraction name first so I
changed the
help file to invoke it that way.
cheers Miller
On Wed, May 11, 2016 at 01:13:37PM -0400, Jaime Oliver wrote: > Well, > > What would happen if instead of calling clone like: > > [clone 16 my-abstraction 1 5 9] > > we called it with: > > [clone my-abstraction 16 1 5 9] > > and then $1 seems quite appropriate. > > ? > > J > > > > > On May 11, 2016, at 12:17 PM, Christof Ressi
christof.ressi@gmx.at wrote:
> > > > I agree that $1 is most natural! > > > > However, what about adding an additional flag -foo for
[clone], which changes the way creation arguments are parsed?
> > Passing -foo could ignore the object ID and rather forward
creation arguments just as they are.
> > > > This wouldn't break the current behaviour of [clone], but
provide some functionality to deal with ordinary abstractions more conveniently.
> > > > Christof > > > > > > > > > >
> >
> > > > Gesendet: Mittwoch, 11. Mai 2016 um 18:06 Uhr > > Von: "Ivica Bukvic" ico@vt.edu > > An: "Miller Puckette" msp@ucsd.edu > > Cc: "IOhannes m zmoelnig" zmoelnig@iem.at, Pd-listpd-list@lists.iem.at, "Christof Ressi" christof.ressi@gmx.at
> > Betreff: Re: [PD] [clone]'s instance number > > What about having an if statement that detects clone object
and if so, compensates for $2 discrepancy and assigns $1 to it instead and increments from there? This way the discrepancy is internalized as opposed to something user needs to deal with.
> > -- > > Ivica Ico Bukvic, D.M.A. > > Associate Professor > > Computer Music > > ICAT Senior Fellow > > Director -- DISIS, L2Ork > > Virginia Tech > > School of Performing Arts – 0141 > > Blacksburg, VA 24061 > > (540) 231-6139 > > ico@vt.edu > > www.performingarts.vt.edu[http://www.performingarts.vt.edu] > > disis.icat.vt.edu[http://disis.icat.vt.edu] > > l2ork.icat.vt.edu[http://l2ork.icat.vt.edu] > > ico.bukvic.net[http://ico.bukvic.net] > > > > On May 11, 2016 11:50, "Miller Puckette"
<msp@ucsd.edu[msp@ucsd.edu]> wrote:I gave this some thought but couldn't come up with anything more natural than
> > the "$1" idea. It allows for changing the other arguments
more easily than
> > it would have been if the instance number were passed last.
Also, somehow
> > it felt more natural to have the instance number first. > > > > If there's interest in the idea, I could add arrguments to
change the
> > behavior (such as putting $1 last instead of first)...
Offhand I doubt that
> > would get used much though. > > > > cheers > > Miller > > > > > > > > On Wed, May 11, 2016 at 05:26:21PM +0200, Christof Ressi
wrote:
> >> 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[zmoelnig@iem.at]>
> >>> An: pd-list@lists.iem.at[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[Pd-list@lists.iem.at] mailing list > >>> UNSUBSCRIBE and account-management ->
https://lists.puredata.info/listinfo/pd-list%5Bhttps://lists.puredata.info/l...]
> >>> > >> > >> _______________________________________________ > >> Pd-list@lists.iem.at[Pd-list@lists.iem.at] mailing list > >> UNSUBSCRIBE and account-management ->
https://lists.puredata.info/listinfo/pd-list%5Bhttps://lists.puredata.info/l...]
> > > > _______________________________________________ > > Pd-list@lists.iem.at[Pd-list@lists.iem.at] mailing list > > UNSUBSCRIBE and account-management ->
https://lists.puredata.info/listinfo/pd-list%5Bhttps://lists.puredata.info/l...]
> > > > _______________________________________________ > > 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
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
BTW: I guess, it's mostly a design question, whether to work with instance numbers inside abstractions and or to work with dispatching via the inlets and outlets. However, I can think of at least two cases where it's necessary to have immediate access to instance numbers inside an abstraction: a) [send~ foo-$1] or [catch~ bar-$1] to disambiguate audio inputs/outputs, because you can't set these two dynamically like [r~] and [throw~]
Where do you envision the corresponding [r~ foo-$1] or [throw~ bar-$1] to reside? If it's in the same abstraction, then $0 ought to work just as well.
b) instantiate another abstraction by the instance number (nested abstractions)
Do you mean something like you have 1-baz.pd, 2-baz.pd, etc. and then inside your [clone] abstraction you've got [$1-baz]? I suppose this is a potential use case.
So the current behaviour of [clone] (passing the instance number as $1) can be important and very useful. The alternative mode I proposed is mainly for convenience but I'm sure it would pay off in the long run!
Gesendet: Mittwoch, 18. Mai 2016 um 18:45 Uhr Von: "Miller Puckette" msp@ucsd.edu An: "Alex Norman" x37v.alex@gmail.com Cc: "Christof Ressi" christof.ressi@gmx.at, Pd-list <
pd-list@lists.iem.at>
Betreff: Re: [PD] [clone]'s instance number
OK... sounds like it's worth putting in. I guess with the one-letter it already takes (-s) I should also add something like a -e flag to put the number argument at the end of the list instead of the beginning, or
something
like that.
cheers Miller
On Wed, May 18, 2016 at 07:20:29AM -0700, Alex Norman wrote:
I see your point, the abstraction need not know it's instance number
since only the messages meant for it would be dispatched to it.. If you don't care about using sends directed to a specific abstraction then the $1 does nothing for you and if the flag to clone could ditch the $1 to instance setting and just set the arguments to the abstraction [clone -flag blah 20 1 2 3] makes 20 copies of blah with args $1=1 $2=2.. You could use more of your existing abstractions as is, using their args the same way with or without clone.
I'm warming up to that idea.
Alex
On May 17, 2016 6:44:51 PM PDT, Christof Ressi christof.ressi@gmx.at
wrote:
you can still disambiguate, because incoming messages are dispatched
by
the instance number and outgoing messages are prepended with it!
My suggestion was mainly concerning all abstractions that work with inlets and outlets (as opposed to sends and receives), where you basically pass a message and get something out. This could be
anything,
from simple message filtering to a perlin noise generator. Or also existing audio modules that work with a message inlet. If there was such a flag, you could take any of these abstractions as they are, control them separately by prepending the instance number and route
the
message output (or use the sum of the audio output).
I guess, people will use [clone] mainly for voice management for synthesizers, granular synthesis, complicated nested patches etc., but I also see a great potential for massive data generation by using existing simple abstractions and cloning them.
Personally, I have many abstractions I would like to use with [clone], but either I'd have to rewrite them or make a wrapper abstraction.
It's
not a big deal, it's just that an alternative forwarding mode would provide some additional convenience (and could also encourage other usages for [clone]).
Anyway, I can totally live without this feature, but would be happy to have it :-).
Gesendet: Mittwoch, 18. Mai 2016 um 02:35 Uhr Von: "Miller Puckette" msp@ucsd.edu An: "Christof Ressi" christof.ressi@gmx.at Cc: Pd-list pd-list@lists.iem.at Betreff: Re: [PD] [clone]'s instance number
I'm not sure... would anyone ever use this feature? The patch in
question
would ahve to take arguments (if not, thre's no problem) but not use
them to
disambiguate the instances (because clone will set them all equal
anyway).
I have trouble imaginig anyone building a patch like that.
cheers Miller
On Wed, May 18, 2016 at 12:54:16AM +0200, Christof Ressi wrote:
What do you think about the idea with a flag for changing the way
creation arguments are forwarded? It would be really handy if you
could
write something like
[clone -flag 100 my-abstraction 5 6 7] and $1 $2 $3 will be
substituted by 5 6 7 instead of [N] 5 6. This way you could use existing abstractions as they are, without the need for writing a wrapper abstraction to handle the creation argument forwarding.
Christof
> Gesendet: Dienstag, 17. Mai 2016 um 04:05 Uhr > Von: "Miller Puckette" msp@ucsd.edu > An: "Jaime Oliver" jaime.oliver2@gmail.com > Cc: "Christof Ressi" christof.ressi@gmx.at, Pd-list
> Betreff: Re: [PD] [clone]'s instance number > > Cool, taking this suggestion. At least for now it will work
either way,
> but it's much more readable with the abstraction name first so I
changed the
> help file to invoke it that way. > > cheers > Miller > > On Wed, May 11, 2016 at 01:13:37PM -0400, Jaime Oliver wrote: > > Well, > > > > What would happen if instead of calling clone like: > > > > [clone 16 my-abstraction 1 5 9] > > > > we called it with: > > > > [clone my-abstraction 16 1 5 9] > > > > and then $1 seems quite appropriate. > > > > ? > > > > J > > > > > > > > > On May 11, 2016, at 12:17 PM, Christof Ressi
christof.ressi@gmx.at wrote:
> > > > > > I agree that $1 is most natural! > > > > > > However, what about adding an additional flag -foo for
[clone], which changes the way creation arguments are parsed?
> > > Passing -foo could ignore the object ID and rather forward
creation arguments just as they are.
> > > > > > This wouldn't break the current behaviour of [clone], but
provide some functionality to deal with ordinary abstractions more conveniently.
> > > > > > Christof > > > > > > > > > > > > > > > > > > > > > > > > Gesendet: Mittwoch, 11. Mai 2016 um 18:06 Uhr > > > Von: "Ivica Bukvic" ico@vt.edu > > > An: "Miller Puckette" msp@ucsd.edu > > > Cc: "IOhannes m zmoelnig" zmoelnig@iem.at, Pd-list
pd-list@lists.iem.at, "Christof Ressi" christof.ressi@gmx.at
> > > Betreff: Re: [PD] [clone]'s instance number > > > What about having an if statement that detects clone object
and if so, compensates for $2 discrepancy and assigns $1 to it instead and increments from there? This way the discrepancy is internalized as opposed to something user needs to deal with.
> > > -- > > > Ivica Ico Bukvic, D.M.A. > > > Associate Professor > > > Computer Music > > > ICAT Senior Fellow > > > Director -- DISIS, L2Ork > > > Virginia Tech > > > School of Performing Arts – 0141 > > > Blacksburg, VA 24061 > > > (540) 231-6139 > > > ico@vt.edu > > > www.performingarts.vt.edu[http://www.performingarts.vt.edu] > > > disis.icat.vt.edu[http://disis.icat.vt.edu] > > > l2ork.icat.vt.edu[http://l2ork.icat.vt.edu] > > > ico.bukvic.net[http://ico.bukvic.net] > > > > > > On May 11, 2016 11:50, "Miller Puckette"
<msp@ucsd.edu[msp@ucsd.edu]> wrote:I gave this some thought but couldn't come up with anything more natural than
> > > the "$1" idea. It allows for changing the other arguments
more easily than
> > > it would have been if the instance number were passed last.
Also, somehow
> > > it felt more natural to have the instance number first. > > > > > > If there's interest in the idea, I could add arrguments to
change the
> > > behavior (such as putting $1 last instead of first)...
Offhand I doubt that
> > > would get used much though. > > > > > > cheers > > > Miller > > > > > > > > > > > > On Wed, May 11, 2016 at 05:26:21PM +0200, Christof Ressi
wrote:
> > >> 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[zmoelnig@iem.at]>
> > >>> An: pd-list@lists.iem.at[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[Pd-list@lists.iem.at] mailing list > > >>> UNSUBSCRIBE and account-management ->
https://lists.puredata.info/listinfo/pd-list%5Bhttps://lists.puredata.info/l...]
> > >>> > > >> > > >> _______________________________________________ > > >> Pd-list@lists.iem.at[Pd-list@lists.iem.at] mailing list > > >> UNSUBSCRIBE and account-management ->
https://lists.puredata.info/listinfo/pd-list%5Bhttps://lists.puredata.info/l...]
> > > > > > _______________________________________________ > > > Pd-list@lists.iem.at[Pd-list@lists.iem.at] mailing list > > > UNSUBSCRIBE and account-management ->
https://lists.puredata.info/listinfo/pd-list%5Bhttps://lists.puredata.info/l...]
> > > > > > _______________________________________________ > > > 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
>
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
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Where do you envision the corresponding [r~ foo-$1] or [throw~ bar-$1] to reside? If it's in the same abstraction, then $0 ought to work just as well.
Outside of [clone]: if you want instances to take different signal inputs or disambiguate the signal output (as [clone] will simply sum at [outlet~]). Could be useful for handling multi-channel audio processing.
Gesendet: Mittwoch, 18. Mai 2016 um 22:40 Uhr Von: "Matt Barber" brbrofsvl@gmail.com An: "Christof Ressi" christof.ressi@gmx.at Cc: "Miller Puckette" msp@ucsd.edu, Pd-list pd-list@lists.iem.at Betreff: Re: [PD] [clone]'s instance number
BTW: I guess, it's mostly a design question, whether to work with instance numbers inside abstractions and or to work with dispatching via the inlets and outlets. However, I can think of at least two cases where it's necessary to have immediate access to instance numbers inside an abstraction: a) [send~ foo-$1] or [catch~ bar-$1] to disambiguate audio inputs/outputs, because you can't set these two dynamically like [r~] and [throw~]
Where do you envision the corresponding [r~ foo-$1] or [throw~ bar-$1] to reside? If it's in the same abstraction, then $0 ought to work just as well. b) instantiate another abstraction by the instance number (nested abstractions)
Do you mean something like you have 1-baz.pd, 2-baz.pd, etc. and then inside your [clone] abstraction you've got [$1-baz]? I suppose this is a potential use case. So the current behaviour of [clone] (passing the instance number as $1) can be important and very useful. The alternative mode I proposed is mainly for convenience but I'm sure it would pay off in the long run!
Gesendet: Mittwoch, 18. Mai 2016 um 18:45 Uhr Von: "Miller Puckette" msp@ucsd.edu An: "Alex Norman" <x37v.alex@gmail.com[x37v.alex@gmail.com]>
Cc: "Christof Ressi" <christof.ressi@gmx.at[christof.ressi@gmx.at]>, Pd-list <pd-list@lists.iem.at[pd-list@lists.iem.at]> Betreff: Re: [PD] [clone]'s instance number
OK... sounds like it's worth putting in. I guess with the one-letter it already takes (-s) I should also add something like a -e flag to put the number argument at the end of the list instead of the beginning, or something like that.
cheers Miller
On Wed, May 18, 2016 at 07:20:29AM -0700, Alex Norman wrote:
I see your point, the abstraction need not know it's instance number since only the messages meant for it would be dispatched to it.. If you don't care about using sends directed to a specific abstraction then the $1 does nothing for you and if the flag to clone could ditch the $1 to instance setting and just set the arguments to the abstraction [clone -flag blah 20 1 2 3] makes 20 copies of blah with args $1=1 $2=2.. You could use more of your existing abstractions as is, using their args the same way with or without clone.
I'm warming up to that idea.
Alex
On May 17, 2016 6:44:51 PM PDT, Christof Ressi <christof.ressi@gmx.at[christof.ressi@gmx.at]> wrote:
you can still disambiguate, because incoming messages are dispatched by the instance number and outgoing messages are prepended with it!
My suggestion was mainly concerning all abstractions that work with inlets and outlets (as opposed to sends and receives), where you basically pass a message and get something out. This could be anything, from simple message filtering to a perlin noise generator. Or also existing audio modules that work with a message inlet. If there was such a flag, you could take any of these abstractions as they are, control them separately by prepending the instance number and route the message output (or use the sum of the audio output).
I guess, people will use [clone] mainly for voice management for synthesizers, granular synthesis, complicated nested patches etc., but I also see a great potential for massive data generation by using existing simple abstractions and cloning them.
Personally, I have many abstractions I would like to use with [clone], but either I'd have to rewrite them or make a wrapper abstraction. It's not a big deal, it's just that an alternative forwarding mode would provide some additional convenience (and could also encourage other usages for [clone]).
Anyway, I can totally live without this feature, but would be happy to have it :-).
Gesendet: Mittwoch, 18. Mai 2016 um 02:35 Uhr Von: "Miller Puckette" <msp@ucsd.edu[msp@ucsd.edu]> An: "Christof Ressi" <christof.ressi@gmx.at[christof.ressi@gmx.at]> Cc: Pd-list <pd-list@lists.iem.at[pd-list@lists.iem.at]> Betreff: Re: [PD] [clone]'s instance number
I'm not sure... would anyone ever use this feature? The patch in
question
would ahve to take arguments (if not, thre's no problem) but not use
them to
disambiguate the instances (because clone will set them all equal
anyway).
I have trouble imaginig anyone building a patch like that.
cheers Miller
On Wed, May 18, 2016 at 12:54:16AM +0200, Christof Ressi wrote:
What do you think about the idea with a flag for changing the way
creation arguments are forwarded? It would be really handy if you could write something like
[clone -flag 100 my-abstraction 5 6 7] and $1 $2 $3 will be
substituted by 5 6 7 instead of [N] 5 6. This way you could use existing abstractions as they are, without the need for writing a wrapper abstraction to handle the creation argument forwarding.
Christof
Gesendet: Dienstag, 17. Mai 2016 um 04:05 Uhr Von: "Miller Puckette" <msp@ucsd.edu[msp@ucsd.edu]> An: "Jaime Oliver" <jaime.oliver2@gmail.com[jaime.oliver2@gmail.com]> Cc: "Christof Ressi" <christof.ressi@gmx.at[christof.ressi@gmx.at]>, Pd-list
<pd-list@lists.iem.at[pd-list@lists.iem.at]>
Betreff: Re: [PD] [clone]'s instance number
Cool, taking this suggestion. At least for now it will work
either way,
but it's much more readable with the abstraction name first so I
changed the
help file to invoke it that way.
cheers Miller
On Wed, May 11, 2016 at 01:13:37PM -0400, Jaime Oliver wrote: > Well, > > What would happen if instead of calling clone like: > > [clone 16 my-abstraction 1 5 9] > > we called it with: > > [clone my-abstraction 16 1 5 9] > > and then $1 seems quite appropriate. > > ? > > J > > > > > On May 11, 2016, at 12:17 PM, Christof Ressi
<christof.ressi@gmx.at[christof.ressi@gmx.at]> wrote:
> > > > I agree that $1 is most natural! > > > > However, what about adding an additional flag -foo for
[clone], which changes the way creation arguments are parsed?
> > Passing -foo could ignore the object ID and rather forward
creation arguments just as they are.
> > > > This wouldn't break the current behaviour of [clone], but
provide some functionality to deal with ordinary abstractions more conveniently.
> > > > Christof > > > > > > > > > > > > > > > > Gesendet: Mittwoch, 11. Mai 2016 um 18:06 Uhr > > Von: "Ivica Bukvic" <ico@vt.edu[ico@vt.edu]> > > An: "Miller Puckette" <msp@ucsd.edu[msp@ucsd.edu]> > > Cc: "IOhannes m zmoelnig" <zmoelnig@iem.at[zmoelnig@iem.at]>, Pd-list
<pd-list@lists.iem.at[pd-list@lists.iem.at]>, "Christof Ressi" <christof.ressi@gmx.at[christof.ressi@gmx.at]>
> > Betreff: Re: [PD] [clone]'s instance number > > What about having an if statement that detects clone object
and if so, compensates for $2 discrepancy and assigns $1 to it instead and increments from there? This way the discrepancy is internalized as opposed to something user needs to deal with.
> > -- > > Ivica Ico Bukvic, D.M.A. > > Associate Professor > > Computer Music > > ICAT Senior Fellow > > Director -- DISIS, L2Ork > > Virginia Tech > > School of Performing Arts – 0141 > > Blacksburg, VA 24061 > > (540) 231-6139 > > ico@vt.edu[ico@vt.edu] > > www.performingarts.vt.edu[http://www.performingarts.vt.edu][http://www.performingarts.vt.edu%5Bhttp://www.performingarts.vt.edu]] > > disis.icat.vt.edu[http://disis.icat.vt.edu][http://disis.icat.vt.edu%5Bhttp://disis.icat.vt.edu]] > > l2ork.icat.vt.edu[http://l2ork.icat.vt.edu][http://l2ork.icat.vt.edu%5Bhttp://l2ork.icat.vt.edu]] > > ico.bukvic.net[http://ico.bukvic.net][http://ico.bukvic.net%5Bhttp://ico.bukvic.net]] > > > > On May 11, 2016 11:50, "Miller Puckette"
<msp@ucsd.edu[msp@ucsd.edu][msp@ucsd.edu[msp@ucsd.edu]]> wrote:I gave this some thought but couldn't come up with anything more natural than
> > the "$1" idea. It allows for changing the other arguments
more easily than
> > it would have been if the instance number were passed last.
Also, somehow
> > it felt more natural to have the instance number first. > > > > If there's interest in the idea, I could add arrguments to
change the
> > behavior (such as putting $1 last instead of first)...
Offhand I doubt that
> > would get used much though. > > > > cheers > > Miller > > > > > > > > On Wed, May 11, 2016 at 05:26:21PM +0200, Christof Ressi
wrote:
> >> 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[zmoelnig@iem.at][zmoelnig@iem.at[zmoelnig@iem.at]]>
> >>> An: pd-list@lists.iem.at[pd-list@lists.iem.at][pd-list@lists.iem.at[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[Pd-list@lists.iem.at][Pd-list@lists.iem.at[Pd-list@lists.iem.at]] mailing list > >>> UNSUBSCRIBE and account-management ->
https://lists.puredata.info/listinfo/pd-list%5Bhttps://lists.puredata.info/l...]]
> >>> > >> > >> _______________________________________________ > >> Pd-list@lists.iem.at[Pd-list@lists.iem.at][Pd-list@lists.iem.at[Pd-list@lists.iem.at]] mailing list > >> UNSUBSCRIBE and account-management ->
https://lists.puredata.info/listinfo/pd-list%5Bhttps://lists.puredata.info/l...]]
> > > > _______________________________________________ > > Pd-list@lists.iem.at[Pd-list@lists.iem.at][Pd-list@lists.iem.at[Pd-list@lists.iem.at]] mailing list > > UNSUBSCRIBE and account-management ->
https://lists.puredata.info/listinfo/pd-list%5Bhttps://lists.puredata.info/l...]]
> > > > _______________________________________________ > > Pd-list@lists.iem.at[Pd-list@lists.iem.at] mailing list > > UNSUBSCRIBE and account-management ->
https://lists.puredata.info/listinfo/pd-list%5Bhttps://lists.puredata.info/l...]
> > > _______________________________________________ > Pd-list@lists.iem.at[Pd-list@lists.iem.at] mailing list > UNSUBSCRIBE and account-management ->
https://lists.puredata.info/listinfo/pd-list%5Bhttps://lists.puredata.info/l...]
Pd-list@lists.iem.at[Pd-list@lists.iem.at] mailing list UNSUBSCRIBE and account-management ->
https://lists.puredata.info/listinfo/pd-list%5Bhttps://lists.puredata.info/l...]
Pd-list@lists.iem.at[Pd-list@lists.iem.at] mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list%5Bhttps://lists.puredata.info/l...]
Pd-list@lists.iem.at[Pd-list@lists.iem.at] mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list%5Bhttps://lists.puredata.info/l...]
Do you mean something like you have 1-baz.pd, 2-baz.pd, etc. and then inside your [clone] abstraction you've got [$1-baz]? I suppose this is a potential use case.
Haha, sorry bad wording from my side, but this also an interesting use case!
I rather meant projects where everything is broken into modules which themselves contain other modules etc. The first module in the tree takes an ID as an *creation argument* and passes it down do its submodules. Something like that.
Gesendet: Mittwoch, 18. Mai 2016 um 22:40 Uhr Von: "Matt Barber" brbrofsvl@gmail.com An: "Christof Ressi" christof.ressi@gmx.at Cc: "Miller Puckette" msp@ucsd.edu, Pd-list pd-list@lists.iem.at Betreff: Re: [PD] [clone]'s instance number
BTW: I guess, it's mostly a design question, whether to work with instance numbers inside abstractions and or to work with dispatching via the inlets and outlets. However, I can think of at least two cases where it's necessary to have immediate access to instance numbers inside an abstraction: a) [send~ foo-$1] or [catch~ bar-$1] to disambiguate audio inputs/outputs, because you can't set these two dynamically like [r~] and [throw~]
Where do you envision the corresponding [r~ foo-$1] or [throw~ bar-$1] to reside? If it's in the same abstraction, then $0 ought to work just as well. b) instantiate another abstraction by the instance number (nested abstractions)
Do you mean something like you have 1-baz.pd, 2-baz.pd, etc. and then inside your [clone] abstraction you've got [$1-baz]? I suppose this is a potential use case. So the current behaviour of [clone] (passing the instance number as $1) can be important and very useful. The alternative mode I proposed is mainly for convenience but I'm sure it would pay off in the long run!
Gesendet: Mittwoch, 18. Mai 2016 um 18:45 Uhr Von: "Miller Puckette" msp@ucsd.edu An: "Alex Norman" <x37v.alex@gmail.com[x37v.alex@gmail.com]>
Cc: "Christof Ressi" <christof.ressi@gmx.at[christof.ressi@gmx.at]>, Pd-list <pd-list@lists.iem.at[pd-list@lists.iem.at]> Betreff: Re: [PD] [clone]'s instance number
OK... sounds like it's worth putting in. I guess with the one-letter it already takes (-s) I should also add something like a -e flag to put the number argument at the end of the list instead of the beginning, or something like that.
cheers Miller
On Wed, May 18, 2016 at 07:20:29AM -0700, Alex Norman wrote:
I see your point, the abstraction need not know it's instance number since only the messages meant for it would be dispatched to it.. If you don't care about using sends directed to a specific abstraction then the $1 does nothing for you and if the flag to clone could ditch the $1 to instance setting and just set the arguments to the abstraction [clone -flag blah 20 1 2 3] makes 20 copies of blah with args $1=1 $2=2.. You could use more of your existing abstractions as is, using their args the same way with or without clone.
I'm warming up to that idea.
Alex
On May 17, 2016 6:44:51 PM PDT, Christof Ressi <christof.ressi@gmx.at[christof.ressi@gmx.at]> wrote:
you can still disambiguate, because incoming messages are dispatched by the instance number and outgoing messages are prepended with it!
My suggestion was mainly concerning all abstractions that work with inlets and outlets (as opposed to sends and receives), where you basically pass a message and get something out. This could be anything, from simple message filtering to a perlin noise generator. Or also existing audio modules that work with a message inlet. If there was such a flag, you could take any of these abstractions as they are, control them separately by prepending the instance number and route the message output (or use the sum of the audio output).
I guess, people will use [clone] mainly for voice management for synthesizers, granular synthesis, complicated nested patches etc., but I also see a great potential for massive data generation by using existing simple abstractions and cloning them.
Personally, I have many abstractions I would like to use with [clone], but either I'd have to rewrite them or make a wrapper abstraction. It's not a big deal, it's just that an alternative forwarding mode would provide some additional convenience (and could also encourage other usages for [clone]).
Anyway, I can totally live without this feature, but would be happy to have it :-).
Gesendet: Mittwoch, 18. Mai 2016 um 02:35 Uhr Von: "Miller Puckette" <msp@ucsd.edu[msp@ucsd.edu]> An: "Christof Ressi" <christof.ressi@gmx.at[christof.ressi@gmx.at]> Cc: Pd-list <pd-list@lists.iem.at[pd-list@lists.iem.at]> Betreff: Re: [PD] [clone]'s instance number
I'm not sure... would anyone ever use this feature? The patch in
question
would ahve to take arguments (if not, thre's no problem) but not use
them to
disambiguate the instances (because clone will set them all equal
anyway).
I have trouble imaginig anyone building a patch like that.
cheers Miller
On Wed, May 18, 2016 at 12:54:16AM +0200, Christof Ressi wrote:
What do you think about the idea with a flag for changing the way
creation arguments are forwarded? It would be really handy if you could write something like
[clone -flag 100 my-abstraction 5 6 7] and $1 $2 $3 will be
substituted by 5 6 7 instead of [N] 5 6. This way you could use existing abstractions as they are, without the need for writing a wrapper abstraction to handle the creation argument forwarding.
Christof
Gesendet: Dienstag, 17. Mai 2016 um 04:05 Uhr Von: "Miller Puckette" <msp@ucsd.edu[msp@ucsd.edu]> An: "Jaime Oliver" <jaime.oliver2@gmail.com[jaime.oliver2@gmail.com]> Cc: "Christof Ressi" <christof.ressi@gmx.at[christof.ressi@gmx.at]>, Pd-list
<pd-list@lists.iem.at[pd-list@lists.iem.at]>
Betreff: Re: [PD] [clone]'s instance number
Cool, taking this suggestion. At least for now it will work
either way,
but it's much more readable with the abstraction name first so I
changed the
help file to invoke it that way.
cheers Miller
On Wed, May 11, 2016 at 01:13:37PM -0400, Jaime Oliver wrote: > Well, > > What would happen if instead of calling clone like: > > [clone 16 my-abstraction 1 5 9] > > we called it with: > > [clone my-abstraction 16 1 5 9] > > and then $1 seems quite appropriate. > > ? > > J > > > > > On May 11, 2016, at 12:17 PM, Christof Ressi
<christof.ressi@gmx.at[christof.ressi@gmx.at]> wrote:
> > > > I agree that $1 is most natural! > > > > However, what about adding an additional flag -foo for
[clone], which changes the way creation arguments are parsed?
> > Passing -foo could ignore the object ID and rather forward
creation arguments just as they are.
> > > > This wouldn't break the current behaviour of [clone], but
provide some functionality to deal with ordinary abstractions more conveniently.
> > > > Christof > > > > > > > > > > > > > > > > Gesendet: Mittwoch, 11. Mai 2016 um 18:06 Uhr > > Von: "Ivica Bukvic" <ico@vt.edu[ico@vt.edu]> > > An: "Miller Puckette" <msp@ucsd.edu[msp@ucsd.edu]> > > Cc: "IOhannes m zmoelnig" <zmoelnig@iem.at[zmoelnig@iem.at]>, Pd-list
<pd-list@lists.iem.at[pd-list@lists.iem.at]>, "Christof Ressi" <christof.ressi@gmx.at[christof.ressi@gmx.at]>
> > Betreff: Re: [PD] [clone]'s instance number > > What about having an if statement that detects clone object
and if so, compensates for $2 discrepancy and assigns $1 to it instead and increments from there? This way the discrepancy is internalized as opposed to something user needs to deal with.
> > -- > > Ivica Ico Bukvic, D.M.A. > > Associate Professor > > Computer Music > > ICAT Senior Fellow > > Director -- DISIS, L2Ork > > Virginia Tech > > School of Performing Arts – 0141 > > Blacksburg, VA 24061 > > (540) 231-6139 > > ico@vt.edu[ico@vt.edu] > > www.performingarts.vt.edu[http://www.performingarts.vt.edu][http://www.performingarts.vt.edu%5Bhttp://www.performingarts.vt.edu]] > > disis.icat.vt.edu[http://disis.icat.vt.edu][http://disis.icat.vt.edu%5Bhttp://disis.icat.vt.edu]] > > l2ork.icat.vt.edu[http://l2ork.icat.vt.edu][http://l2ork.icat.vt.edu%5Bhttp://l2ork.icat.vt.edu]] > > ico.bukvic.net[http://ico.bukvic.net][http://ico.bukvic.net%5Bhttp://ico.bukvic.net]] > > > > On May 11, 2016 11:50, "Miller Puckette"
<msp@ucsd.edu[msp@ucsd.edu][msp@ucsd.edu[msp@ucsd.edu]]> wrote:I gave this some thought but couldn't come up with anything more natural than
> > the "$1" idea. It allows for changing the other arguments
more easily than
> > it would have been if the instance number were passed last.
Also, somehow
> > it felt more natural to have the instance number first. > > > > If there's interest in the idea, I could add arrguments to
change the
> > behavior (such as putting $1 last instead of first)...
Offhand I doubt that
> > would get used much though. > > > > cheers > > Miller > > > > > > > > On Wed, May 11, 2016 at 05:26:21PM +0200, Christof Ressi
wrote:
> >> 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[zmoelnig@iem.at][zmoelnig@iem.at[zmoelnig@iem.at]]>
> >>> An: pd-list@lists.iem.at[pd-list@lists.iem.at][pd-list@lists.iem.at[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[Pd-list@lists.iem.at][Pd-list@lists.iem.at[Pd-list@lists.iem.at]] mailing list > >>> UNSUBSCRIBE and account-management ->
https://lists.puredata.info/listinfo/pd-list%5Bhttps://lists.puredata.info/l...]]
> >>> > >> > >> _______________________________________________ > >> Pd-list@lists.iem.at[Pd-list@lists.iem.at][Pd-list@lists.iem.at[Pd-list@lists.iem.at]] mailing list > >> UNSUBSCRIBE and account-management ->
https://lists.puredata.info/listinfo/pd-list%5Bhttps://lists.puredata.info/l...]]
> > > > _______________________________________________ > > Pd-list@lists.iem.at[Pd-list@lists.iem.at][Pd-list@lists.iem.at[Pd-list@lists.iem.at]] mailing list > > UNSUBSCRIBE and account-management ->
https://lists.puredata.info/listinfo/pd-list%5Bhttps://lists.puredata.info/l...]]
> > > > _______________________________________________ > > Pd-list@lists.iem.at[Pd-list@lists.iem.at] mailing list > > UNSUBSCRIBE and account-management ->
https://lists.puredata.info/listinfo/pd-list%5Bhttps://lists.puredata.info/l...]
> > > _______________________________________________ > Pd-list@lists.iem.at[Pd-list@lists.iem.at] mailing list > UNSUBSCRIBE and account-management ->
https://lists.puredata.info/listinfo/pd-list%5Bhttps://lists.puredata.info/l...]
Pd-list@lists.iem.at[Pd-list@lists.iem.at] mailing list UNSUBSCRIBE and account-management ->
https://lists.puredata.info/listinfo/pd-list%5Bhttps://lists.puredata.info/l...]
Pd-list@lists.iem.at[Pd-list@lists.iem.at] mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list%5Bhttps://lists.puredata.info/l...]
Pd-list@lists.iem.at[Pd-list@lists.iem.at] mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list%5Bhttps://lists.puredata.info/l...]
OK... I'm talked into it. Should appear (as a "-x" optional flag) once 0.47-1 is ready.
cheers Miller
On Wed, May 18, 2016 at 11:07:36PM +0200, Christof Ressi wrote:
Do you mean something like you have 1-baz.pd, 2-baz.pd, etc. and then inside your [clone] abstraction you've got [$1-baz]? I suppose this is a potential use case.
Haha, sorry bad wording from my side, but this also an interesting use case!
I rather meant projects where everything is broken into modules which themselves contain other modules etc. The first module in the tree takes an ID as an *creation argument* and passes it down do its submodules. Something like that.
Gesendet: Mittwoch, 18. Mai 2016 um 22:40 Uhr Von: "Matt Barber" brbrofsvl@gmail.com An: "Christof Ressi" christof.ressi@gmx.at Cc: "Miller Puckette" msp@ucsd.edu, Pd-list pd-list@lists.iem.at Betreff: Re: [PD] [clone]'s instance number
BTW: I guess, it's mostly a design question, whether to work with instance numbers inside abstractions and or to work with dispatching via the inlets and outlets. However, I can think of at least two cases where it's necessary to have immediate access to instance numbers inside an abstraction: a) [send~ foo-$1] or [catch~ bar-$1] to disambiguate audio inputs/outputs, because you can't set these two dynamically like [r~] and [throw~]
Where do you envision the corresponding [r~ foo-$1] or [throw~ bar-$1] to reside? If it's in the same abstraction, then $0 ought to work just as well. b) instantiate another abstraction by the instance number (nested abstractions)
Do you mean something like you have 1-baz.pd, 2-baz.pd, etc. and then inside your [clone] abstraction you've got [$1-baz]? I suppose this is a potential use case. So the current behaviour of [clone] (passing the instance number as $1) can be important and very useful. The alternative mode I proposed is mainly for convenience but I'm sure it would pay off in the long run!
Gesendet: Mittwoch, 18. Mai 2016 um 18:45 Uhr Von: "Miller Puckette" msp@ucsd.edu An: "Alex Norman" <x37v.alex@gmail.com[x37v.alex@gmail.com]>
Cc: "Christof Ressi" <christof.ressi@gmx.at[christof.ressi@gmx.at]>, Pd-list <pd-list@lists.iem.at[pd-list@lists.iem.at]> Betreff: Re: [PD] [clone]'s instance number
OK... sounds like it's worth putting in. I guess with the one-letter it already takes (-s) I should also add something like a -e flag to put the number argument at the end of the list instead of the beginning, or something like that.
cheers Miller
On Wed, May 18, 2016 at 07:20:29AM -0700, Alex Norman wrote:
I see your point, the abstraction need not know it's instance number since only the messages meant for it would be dispatched to it.. If you don't care about using sends directed to a specific abstraction then the $1 does nothing for you and if the flag to clone could ditch the $1 to instance setting and just set the arguments to the abstraction [clone -flag blah 20 1 2 3] makes 20 copies of blah with args $1=1 $2=2.. You could use more of your existing abstractions as is, using their args the same way with or without clone.
I'm warming up to that idea.
Alex
On May 17, 2016 6:44:51 PM PDT, Christof Ressi <christof.ressi@gmx.at[christof.ressi@gmx.at]> wrote:
you can still disambiguate, because incoming messages are dispatched by the instance number and outgoing messages are prepended with it!
My suggestion was mainly concerning all abstractions that work with inlets and outlets (as opposed to sends and receives), where you basically pass a message and get something out. This could be anything, from simple message filtering to a perlin noise generator. Or also existing audio modules that work with a message inlet. If there was such a flag, you could take any of these abstractions as they are, control them separately by prepending the instance number and route the message output (or use the sum of the audio output).
I guess, people will use [clone] mainly for voice management for synthesizers, granular synthesis, complicated nested patches etc., but I also see a great potential for massive data generation by using existing simple abstractions and cloning them.
Personally, I have many abstractions I would like to use with [clone], but either I'd have to rewrite them or make a wrapper abstraction. It's not a big deal, it's just that an alternative forwarding mode would provide some additional convenience (and could also encourage other usages for [clone]).
Anyway, I can totally live without this feature, but would be happy to have it :-).
Gesendet: Mittwoch, 18. Mai 2016 um 02:35 Uhr Von: "Miller Puckette" <msp@ucsd.edu[msp@ucsd.edu]> An: "Christof Ressi" <christof.ressi@gmx.at[christof.ressi@gmx.at]> Cc: Pd-list <pd-list@lists.iem.at[pd-list@lists.iem.at]> Betreff: Re: [PD] [clone]'s instance number
I'm not sure... would anyone ever use this feature? The patch in
question
would ahve to take arguments (if not, thre's no problem) but not use
them to
disambiguate the instances (because clone will set them all equal
anyway).
I have trouble imaginig anyone building a patch like that.
cheers Miller
On Wed, May 18, 2016 at 12:54:16AM +0200, Christof Ressi wrote:
What do you think about the idea with a flag for changing the way
creation arguments are forwarded? It would be really handy if you could write something like
[clone -flag 100 my-abstraction 5 6 7] and $1 $2 $3 will be
substituted by 5 6 7 instead of [N] 5 6. This way you could use existing abstractions as they are, without the need for writing a wrapper abstraction to handle the creation argument forwarding.
Christof
> Gesendet: Dienstag, 17. Mai 2016 um 04:05 Uhr > Von: "Miller Puckette" <msp@ucsd.edu[msp@ucsd.edu]> > An: "Jaime Oliver" <jaime.oliver2@gmail.com[jaime.oliver2@gmail.com]> > Cc: "Christof Ressi" <christof.ressi@gmx.at[christof.ressi@gmx.at]>, Pd-list
<pd-list@lists.iem.at[pd-list@lists.iem.at]>
> Betreff: Re: [PD] [clone]'s instance number > > Cool, taking this suggestion. At least for now it will work
either way,
> but it's much more readable with the abstraction name first so I
changed the
> help file to invoke it that way. > > cheers > Miller > > On Wed, May 11, 2016 at 01:13:37PM -0400, Jaime Oliver wrote: > > Well, > > > > What would happen if instead of calling clone like: > > > > [clone 16 my-abstraction 1 5 9] > > > > we called it with: > > > > [clone my-abstraction 16 1 5 9] > > > > and then $1 seems quite appropriate. > > > > ? > > > > J > > > > > > > > > On May 11, 2016, at 12:17 PM, Christof Ressi
<christof.ressi@gmx.at[christof.ressi@gmx.at]> wrote:
> > > > > > I agree that $1 is most natural! > > > > > > However, what about adding an additional flag -foo for
[clone], which changes the way creation arguments are parsed?
> > > Passing -foo could ignore the object ID and rather forward
creation arguments just as they are.
> > > > > > This wouldn't break the current behaviour of [clone], but
provide some functionality to deal with ordinary abstractions more conveniently.
> > > > > > Christof > > > > > > > > > > > > > > > > > > > > > > > > Gesendet: Mittwoch, 11. Mai 2016 um 18:06 Uhr > > > Von: "Ivica Bukvic" <ico@vt.edu[ico@vt.edu]> > > > An: "Miller Puckette" <msp@ucsd.edu[msp@ucsd.edu]> > > > Cc: "IOhannes m zmoelnig" <zmoelnig@iem.at[zmoelnig@iem.at]>, Pd-list
<pd-list@lists.iem.at[pd-list@lists.iem.at]>, "Christof Ressi" <christof.ressi@gmx.at[christof.ressi@gmx.at]>
> > > Betreff: Re: [PD] [clone]'s instance number > > > What about having an if statement that detects clone object
and if so, compensates for $2 discrepancy and assigns $1 to it instead and increments from there? This way the discrepancy is internalized as opposed to something user needs to deal with.
> > > -- > > > Ivica Ico Bukvic, D.M.A. > > > Associate Professor > > > Computer Music > > > ICAT Senior Fellow > > > Director -- DISIS, L2Ork > > > Virginia Tech > > > School of Performing Arts – 0141 > > > Blacksburg, VA 24061 > > > (540) 231-6139 > > > ico@vt.edu[ico@vt.edu] > > > www.performingarts.vt.edu[http://www.performingarts.vt.edu][http://www.performingarts.vt.edu%5Bhttp://www.performingarts.vt.edu]] > > > disis.icat.vt.edu[http://disis.icat.vt.edu][http://disis.icat.vt.edu%5Bhttp://disis.icat.vt.edu]] > > > l2ork.icat.vt.edu[http://l2ork.icat.vt.edu][http://l2ork.icat.vt.edu%5Bhttp://l2ork.icat.vt.edu]] > > > ico.bukvic.net[http://ico.bukvic.net][http://ico.bukvic.net%5Bhttp://ico.bukvic.net]] > > > > > > On May 11, 2016 11:50, "Miller Puckette"
<msp@ucsd.edu[msp@ucsd.edu][msp@ucsd.edu[msp@ucsd.edu]]> wrote:I gave this some thought but couldn't come up with anything more natural than
> > > the "$1" idea. It allows for changing the other arguments
more easily than
> > > it would have been if the instance number were passed last.
Also, somehow
> > > it felt more natural to have the instance number first. > > > > > > If there's interest in the idea, I could add arrguments to
change the
> > > behavior (such as putting $1 last instead of first)...
Offhand I doubt that
> > > would get used much though. > > > > > > cheers > > > Miller > > > > > > > > > > > > On Wed, May 11, 2016 at 05:26:21PM +0200, Christof Ressi
wrote:
> > >> 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[zmoelnig@iem.at][zmoelnig@iem.at[zmoelnig@iem.at]]>
> > >>> An: pd-list@lists.iem.at[pd-list@lists.iem.at][pd-list@lists.iem.at[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[Pd-list@lists.iem.at][Pd-list@lists.iem.at[Pd-list@lists.iem.at]] mailing list > > >>> UNSUBSCRIBE and account-management ->
https://lists.puredata.info/listinfo/pd-list%5Bhttps://lists.puredata.info/l...]]
> > >>> > > >> > > >> _______________________________________________ > > >> Pd-list@lists.iem.at[Pd-list@lists.iem.at][Pd-list@lists.iem.at[Pd-list@lists.iem.at]] mailing list > > >> UNSUBSCRIBE and account-management ->
https://lists.puredata.info/listinfo/pd-list%5Bhttps://lists.puredata.info/l...]]
> > > > > > _______________________________________________ > > > Pd-list@lists.iem.at[Pd-list@lists.iem.at][Pd-list@lists.iem.at[Pd-list@lists.iem.at]] mailing list > > > UNSUBSCRIBE and account-management ->
https://lists.puredata.info/listinfo/pd-list%5Bhttps://lists.puredata.info/l...]]
> > > > > > _______________________________________________ > > > Pd-list@lists.iem.at[Pd-list@lists.iem.at] mailing list > > > UNSUBSCRIBE and account-management ->
https://lists.puredata.info/listinfo/pd-list%5Bhttps://lists.puredata.info/l...]
> > > > > > _______________________________________________ > > Pd-list@lists.iem.at[Pd-list@lists.iem.at] mailing list > > UNSUBSCRIBE and account-management ->
https://lists.puredata.info/listinfo/pd-list%5Bhttps://lists.puredata.info/l...]
>
Pd-list@lists.iem.at[Pd-list@lists.iem.at] mailing list UNSUBSCRIBE and account-management ->
https://lists.puredata.info/listinfo/pd-list%5Bhttps://lists.puredata.info/l...]
Pd-list@lists.iem.at[Pd-list@lists.iem.at] mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list%5Bhttps://lists.puredata.info/l...]
Pd-list@lists.iem.at[Pd-list@lists.iem.at] mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list%5Bhttps://lists.puredata.info/l...]
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Awesome!
On May 18, 2016 8:01:24 PM PDT, Miller Puckette msp@ucsd.edu wrote:
OK... I'm talked into it. Should appear (as a "-x" optional flag) once 0.47-1 is ready.
cheers Miller
On Wed, May 18, 2016 at 11:07:36PM +0200, Christof Ressi wrote:
Do you mean something like you have 1-baz.pd, 2-baz.pd, etc. and
then inside your [clone] abstraction you've got [$1-baz]? I suppose this is a potential use case.
Haha, sorry bad wording from my side, but this also an interesting
use case!
I rather meant projects where everything is broken into modules which
themselves contain other modules etc. The first module in the tree takes an ID as an *creation argument* and passes it down do its submodules. Something like that.
Gesendet: Mittwoch, 18. Mai 2016 um 22:40 Uhr Von: "Matt Barber" brbrofsvl@gmail.com An: "Christof Ressi" christof.ressi@gmx.at Cc: "Miller Puckette" msp@ucsd.edu, Pd-list pd-list@lists.iem.at Betreff: Re: [PD] [clone]'s instance number
BTW: I guess, it's mostly a design question, whether to work with
instance numbers inside abstractions and or to work with dispatching via the inlets and outlets. However, I can think of at least two cases where it's necessary to have immediate access to instance numbers inside an abstraction:
a) [send~ foo-$1] or [catch~ bar-$1] to disambiguate audio
inputs/outputs, because you can't set these two dynamically like [r~] and [throw~]
Where do you envision the corresponding [r~ foo-$1] or [throw~
bar-$1] to reside? If it's in the same abstraction, then $0 ought to work just as well.
b) instantiate another abstraction by the instance number (nested
abstractions)
Do you mean something like you have 1-baz.pd, 2-baz.pd, etc. and
then inside your [clone] abstraction you've got [$1-baz]? I suppose this is a potential use case.
So the current behaviour of [clone] (passing the instance number as
$1) can be important and very useful. The alternative mode I proposed is mainly for convenience but I'm sure it would pay off in the long run!
Gesendet: Mittwoch, 18. Mai 2016 um 18:45 Uhr Von: "Miller Puckette" msp@ucsd.edu An: "Alex Norman" <x37v.alex@gmail.com[x37v.alex@gmail.com]>
Cc: "Christof Ressi"
<christof.ressi@gmx.at[christof.ressi@gmx.at]>, Pd-list <pd-list@lists.iem.at[pd-list@lists.iem.at]>
Betreff: Re: [PD] [clone]'s instance number
OK... sounds like it's worth putting in. I guess with the
one-letter it
already takes (-s) I should also add something like a -e flag to
put the
number argument at the end of the list instead of the beginning, or
something
like that.
cheers Miller
On Wed, May 18, 2016 at 07:20:29AM -0700, Alex Norman wrote:
I see your point, the abstraction need not know it's instance
number since only the messages meant for it would be dispatched to it.. If you don't care about using sends directed to a specific abstraction then the $1 does nothing for you and if the flag to clone could ditch the $1 to instance setting and just set the arguments to the abstraction [clone -flag blah 20 1 2 3] makes 20 copies of blah with args $1=1 $2=2.. You could use more of your existing abstractions as is, using their args the same way with or without clone.
I'm warming up to that idea.
Alex
On May 17, 2016 6:44:51 PM PDT, Christof Ressi
<christof.ressi@gmx.at[christof.ressi@gmx.at]> wrote:
you can still disambiguate, because incoming messages are
dispatched by
the instance number and outgoing messages are prepended with it!
My suggestion was mainly concerning all abstractions that work
with
inlets and outlets (as opposed to sends and receives), where you basically pass a message and get something out. This could be
anything,
from simple message filtering to a perlin noise generator. Or
also
existing audio modules that work with a message inlet. If there
was
such a flag, you could take any of these abstractions as they
are,
control them separately by prepending the instance number and
route the
message output (or use the sum of the audio output).
I guess, people will use [clone] mainly for voice management for synthesizers, granular synthesis, complicated nested patches
etc., but
I also see a great potential for massive data generation by
using
existing simple abstractions and cloning them.
Personally, I have many abstractions I would like to use with
[clone],
but either I'd have to rewrite them or make a wrapper
abstraction. It's
not a big deal, it's just that an alternative forwarding mode
would
provide some additional convenience (and could also encourage
other
usages for [clone]).
Anyway, I can totally live without this feature, but would be
happy to
have it :-).
Gesendet: Mittwoch, 18. Mai 2016 um 02:35 Uhr Von: "Miller Puckette" <msp@ucsd.edu[msp@ucsd.edu]> An: "Christof Ressi"
<christof.ressi@gmx.at[christof.ressi@gmx.at]>
Cc: Pd-list <pd-list@lists.iem.at[pd-list@lists.iem.at]> Betreff: Re: [PD] [clone]'s instance number
I'm not sure... would anyone ever use this feature? The patch
in
question
would ahve to take arguments (if not, thre's no problem) but
not use
them to
disambiguate the instances (because clone will set them all
equal
anyway).
I have trouble imaginig anyone building a patch like that.
cheers Miller
On Wed, May 18, 2016 at 12:54:16AM +0200, Christof Ressi
wrote:
> What do you think about the idea with a flag for changing
the way
creation arguments are forwarded? It would be really handy if
you could
write something like
> [clone -flag 100 my-abstraction 5 6 7] and $1 $2 $3 will be
substituted by 5 6 7 instead of [N] 5 6. This way you could use existing abstractions as they are, without the need for writing
a
wrapper abstraction to handle the creation argument forwarding.
> > Christof > > > Gesendet: Dienstag, 17. Mai 2016 um 04:05 Uhr > > Von: "Miller Puckette" <msp@ucsd.edu[msp@ucsd.edu]> > > An: "Jaime Oliver"
<jaime.oliver2@gmail.com[jaime.oliver2@gmail.com]>
> > Cc: "Christof Ressi"
<christof.ressi@gmx.at[christof.ressi@gmx.at]>, Pd-list
<pd-list@lists.iem.at[pd-list@lists.iem.at]>
> > Betreff: Re: [PD] [clone]'s instance number > > > > Cool, taking this suggestion. At least for now it will
work
either way,
> > but it's much more readable with the abstraction name
first so I
changed the
> > help file to invoke it that way. > > > > cheers > > Miller > > > > On Wed, May 11, 2016 at 01:13:37PM -0400, Jaime Oliver
wrote:
> > > Well, > > > > > > What would happen if instead of calling clone like: > > > > > > [clone 16 my-abstraction 1 5 9] > > > > > > we called it with: > > > > > > [clone my-abstraction 16 1 5 9] > > > > > > and then $1 seems quite appropriate. > > > > > > ? > > > > > > J > > > > > > > > > > > > > On May 11, 2016, at 12:17 PM, Christof Ressi
<christof.ressi@gmx.at[christof.ressi@gmx.at]> wrote:
> > > > > > > > I agree that $1 is most natural! > > > > > > > > However, what about adding an additional flag -foo for
[clone], which changes the way creation arguments are parsed?
> > > > Passing -foo could ignore the object ID and rather
forward
creation arguments just as they are.
> > > > > > > > This wouldn't break the current behaviour of [clone],
but
provide some functionality to deal with ordinary abstractions
more
conveniently.
> > > > > > > > Christof > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Gesendet: Mittwoch, 11. Mai 2016 um 18:06 Uhr > > > > Von: "Ivica Bukvic" <ico@vt.edu[ico@vt.edu]> > > > > An: "Miller Puckette" <msp@ucsd.edu[msp@ucsd.edu]> > > > > Cc: "IOhannes m zmoelnig"
<zmoelnig@iem.at[zmoelnig@iem.at]>, Pd-list
<pd-list@lists.iem.at[pd-list@lists.iem.at]>, "Christof Ressi"
<christof.ressi@gmx.at[christof.ressi@gmx.at]>
> > > > Betreff: Re: [PD] [clone]'s instance number > > > > What about having an if statement that detects clone
object
and if so, compensates for $2 discrepancy and assigns $1 to it
instead
and increments from there? This way the discrepancy is
internalized as
opposed to something user needs to deal with.
> > > > -- > > > > Ivica Ico Bukvic, D.M.A. > > > > Associate Professor > > > > Computer Music > > > > ICAT Senior Fellow > > > > Director -- DISIS, L2Ork > > > > Virginia Tech > > > > School of Performing Arts – 0141 > > > > Blacksburg, VA 24061 > > > > (540) 231-6139 > > > > ico@vt.edu[ico@vt.edu] > > > >
www.performingarts.vt.edu[http://www.performingarts.vt.edu][http://www.performingarts.vt.edu%5Bhttp://www.performingarts.vt.edu]]
> > > >
disis.icat.vt.edu[http://disis.icat.vt.edu][http://disis.icat.vt.edu%5Bhttp://disis.icat.vt.edu]]
> > > >
l2ork.icat.vt.edu[http://l2ork.icat.vt.edu][http://l2ork.icat.vt.edu%5Bhttp://l2ork.icat.vt.edu]]
> > > >
ico.bukvic.net[http://ico.bukvic.net][http://ico.bukvic.net%5Bhttp://ico.bukvic.net]]
> > > > > > > > On May 11, 2016 11:50, "Miller Puckette"
<msp@ucsd.edu[msp@ucsd.edu][msp@ucsd.edu[msp@ucsd.edu]]> wrote:I
gave this some thought but
couldn't come up with anything more natural than
> > > > the "$1" idea. It allows for changing the other
arguments
more easily than
> > > > it would have been if the instance number were passed
last.
Also, somehow
> > > > it felt more natural to have the instance number
first.
> > > > > > > > If there's interest in the idea, I could add
arrguments to
change the
> > > > behavior (such as putting $1 last instead of first)...
Offhand I doubt that
> > > > would get used much though. > > > > > > > > cheers > > > > Miller > > > > > > > > > > > > > > > > On Wed, May 11, 2016 at 05:26:21PM +0200, Christof
Ressi
wrote:
> > > >> 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[zmoelnig@iem.at][zmoelnig@iem.at[zmoelnig@iem.at]]>
> > > >>> An:
pd-list@lists.iem.at[pd-list@lists.iem.at][pd-list@lists.iem.at[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[Pd-list@lists.iem.at][Pd-list@lists.iem.at[Pd-list@lists.iem.at]] mailing list
> > > >>> UNSUBSCRIBE and account-management ->
https://lists.puredata.info/listinfo/pd-list%5Bhttps://lists.puredata.info/l...]]
> > > >>> > > > >> > > > >> _______________________________________________ > > > >>
Pd-list@lists.iem.at[Pd-list@lists.iem.at][Pd-list@lists.iem.at[Pd-list@lists.iem.at]] mailing list
> > > >> UNSUBSCRIBE and account-management ->
https://lists.puredata.info/listinfo/pd-list%5Bhttps://lists.puredata.info/l...]]
> > > > > > > > _______________________________________________ > > > >
Pd-list@lists.iem.at[Pd-list@lists.iem.at][Pd-list@lists.iem.at[Pd-list@lists.iem.at]] mailing list
> > > > UNSUBSCRIBE and account-management ->
https://lists.puredata.info/listinfo/pd-list%5Bhttps://lists.puredata.info/l...]]
> > > > > > > > _______________________________________________ > > > > Pd-list@lists.iem.at[Pd-list@lists.iem.at] mailing
list
> > > > UNSUBSCRIBE and account-management ->
https://lists.puredata.info/listinfo/pd-list%5Bhttps://lists.puredata.info/l...]
> > > > > > > > > _______________________________________________ > > > Pd-list@lists.iem.at[Pd-list@lists.iem.at] mailing list > > > UNSUBSCRIBE and account-management ->
https://lists.puredata.info/listinfo/pd-list%5Bhttps://lists.puredata.info/l...]
> > > > _______________________________________________ > Pd-list@lists.iem.at[Pd-list@lists.iem.at] mailing list > UNSUBSCRIBE and account-management ->
https://lists.puredata.info/listinfo/pd-list%5Bhttps://lists.puredata.info/l...]
Pd-list@lists.iem.at[Pd-list@lists.iem.at] mailing list UNSUBSCRIBE and account-management ->
https://lists.puredata.info/listinfo/pd-list%5Bhttps://lists.puredata.info/l...]
Pd-list@lists.iem.at[Pd-list@lists.iem.at] mailing list UNSUBSCRIBE and account-management ->
https://lists.puredata.info/listinfo/pd-list%5Bhttps://lists.puredata.info/l...]
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
Thanks a lot!!! Looking forward to the release!
Gesendet: Donnerstag, 19. Mai 2016 um 06:50 Uhr Von: "Alex Norman" x37v.alex@gmail.com An: "Miller Puckette" msp@ucsd.edu, "Christof Ressi" christof.ressi@gmx.at Cc: Pd-list pd-list@lists.iem.at Betreff: Re: [PD] [clone]'s instance number Awesome! On May 18, 2016 8:01:24 PM PDT, Miller Puckette msp@ucsd.edu wrote: OK... I'm talked into it. Should appear (as a "-x" optional flag) once 0.47-1 is ready.
cheers Miller
On Wed, May 18, 2016 at 11:07:36PM +0200, Christof Ressi wrote: Do you mean something like you have 1-baz.pd, 2-baz.pd, etc. and then inside your [clone] abstraction you've got [$1-baz]? I suppose this is a potential use case. Haha, sorry bad wording from my side, but this also an interesting use case!
I rather meant projects where everything is broken into modules which themselves contain other modules etc. The first module in the tree takes an ID as an *creation argument* and passes it down do its submodules. Something like that.
Gesendet: Mittwoch, 18. Mai 2016 um 22:40 Uhr Von: "Matt Barber" brbrofsvl@gmail.com An: "Christof Ressi" christof.ressi@gmx.at Cc: "Miller Puckette" msp@ucsd.edu, Pd-list pd-list@lists.iem.at Betreff: Re: [PD] [clone]'s instance number
BTW: I guess, it's mostly a design question, whether to work with instance numbers inside abstractions and or to work with dispatching via the inlets and outlets. However, I can think of at least two cases where it's necessary to have immediate access to instance numbers inside an abstraction: a) [send~ foo-$1] or [catch~ bar-$1] to disambiguate audio inputs/outputs, because you can't set these two dynamically like [r~] and [throw~]
Where do you envision the corresponding [r~ foo-$1] or [throw~ bar-$1] to reside? If it's in the same abstraction, then $0 ought to work just as well. b) instantiate another abstraction by the instance number (nested abstractions)
Do you mean something like you have 1-baz.pd, 2-baz.pd, etc. and then inside your [clone] abstraction you've got [$1-baz]? I suppose this is a potential use case. So the current behaviour of [clone] (passing the instance number as $1) can be important and very useful. The alternative mode I proposed is mainly for convenience but I'm sure it would pay off in the long run! Gesendet: Mittwoch, 18. Mai 2016 um 18:45 Uhr Von: "Miller Puckette" msp@ucsd.edu An: "Alex Norman" <x37v.alex@gmail.com[x37v.alex@gmail.com]> Cc: "Christof Ressi" <christof.ressi@gmx.at[christof.ressi@gmx.at]>, Pd-list <pd-list@lists.iem.at[pd-list@lists.iem.at]> Betreff: Re: [PD] [clone]'s instance number
OK... sounds like it's worth putting in. I guess with the one-letter it already takes (-s) I should also add something like a -e flag to put the number argument at the end of the list instead of the beginning, or something like that.
cheers Miller
On Wed, May 18, 2016 at 07:20:29AM -0700, Alex Norman wrote:I see your point, the abstraction need not know it's instance number since only the messages meant for it would be dispatched to it.. If you don't care about using sends directed to a specific abstraction then the $1 does nothing for you and if the flag to clone could ditch the $1 to instance setting and just set the arguments to the abstraction [clone -flag blah 20 1 2 3] makes 20 copies of blah with args $1=1 $2=2.. You could use more of your existing abstractions as is, using their args the same way with or without clone.
I'm warming up to that idea.
Alex
On May 17, 2016 6:44:51 PM PDT, Christof Ressi <christof.ressi@gmx.at[christof.ressi@gmx.at]> wrote:you can still disambiguate, because incoming messages are dispatched by the instance number and outgoing messages are prepended with it!
My suggestion was mainly concerning all abstractions that work with inlets and outlets (as opposed to sends and receives), where you basically pass a message and get something out. This could be anything, from simple message filtering to a perlin noise generator. Or also existing audio modules that work with a message inlet. If there was such a flag, you could take any of these abstractions as they are, control them separately by prepending the instance number and route the message output (or use the sum of the audio output).
I guess, people will use [clone] mainly for voice management for synthesizers, granular synthesis, complicated nested patches etc., but I also see a great potential for massive data generation by using existing simple abstractions and cloning them.
Personally, I have many abstractions I would like to use with [clone], but either I'd have to rewrite them or make a wrapper abstraction. It's not a big deal, it's just that an alternative forwarding mode would provide some additional convenience (and could also encourage other usages for [clone]).
Anyway, I can totally live without this feature, but would be happy to have it :-). Gesendet: Mittwoch, 18. Mai 2016 um 02:35 Uhr Von: "Miller Puckette" <msp@ucsd.edu[msp@ucsd.edu]> An: "Christof Ressi" <christof.ressi@gmx.at[christof.ressi@gmx.at]> Cc: Pd-list <pd-list@lists.iem.at[pd-list@lists.iem.at]> Betreff: Re: [PD] [clone]'s instance number
I'm not sure... would anyone ever use this feature? The patch inquestionwould ahve to take arguments (if not, thre's no problem) but not usethem todisambiguate the instances (because clone will set them all equalanyway).I have trouble imaginig anyone building a patch like that.
cheers Miller
On Wed, May 18, 2016 at 12:54:16AM +0200, Christof Ressi wrote:What do you think about the idea with a flag for changing the waycreation arguments are forwarded? It would be really handy if you could write something like[clone -flag 100 my-abstraction 5 6 7] and $1 $2 $3 will besubstituted by 5 6 7 instead of [N] 5 6. This way you could use existing abstractions as they are, without the need for writing a wrapper abstraction to handle the creation argument forwarding. Christof Gesendet: Dienstag, 17. Mai 2016 um 04:05 Uhr Von: "Miller Puckette" <msp@ucsd.edu[msp@ucsd.edu]> An: "Jaime Oliver" <jaime.oliver2@gmail.com[jaime.oliver2@gmail.com]> Cc: "Christof Ressi" <christof.ressi@gmx.at[christof.ressi@gmx.at]>, Pd-list<pd-list@lists.iem.at[pd-list@lists.iem.at]>Betreff: Re: [PD] [clone]'s instance number
Cool, taking this suggestion. At least for now it will workeither way,but it's much more readable with the abstraction name first so Ichanged thehelp file to invoke it that way.
cheers Miller
On Wed, May 11, 2016 at 01:13:37PM -0400, Jaime Oliver wrote:Well,
What would happen if instead of calling clone like:
[clone 16 my-abstraction 1 5 9]
we called it with:
[clone my-abstraction 16 1 5 9]
and then $1 seems quite appropriate.
?
J
On May 11, 2016, at 12:17 PM, Christof Ressi<christof.ressi@gmx.at[christof.ressi@gmx.at]> wrote: I agree that $1 is most natural!
However, what about adding an additional flag -foo for[clone], which changes the way creation arguments are parsed?Passing -foo could ignore the object ID and rather forwardcreation arguments just as they are. This wouldn't break the current behaviour of [clone], butprovide some functionality to deal with ordinary abstractions more conveniently. Christof
Gesendet: Mittwoch, 11. Mai 2016 um 18:06 Uhr Von: "Ivica Bukvic" <ico@vt.edu[ico@vt.edu]> An: "Miller Puckette" <msp@ucsd.edu[msp@ucsd.edu]> Cc: "IOhannes m zmoelnig" <zmoelnig@iem.at[zmoelnig@iem.at]>, Pd-list<pd-list@lists.iem.at[pd-list@lists.iem.at]>, "Christof Ressi" <christof.ressi@gmx.at[christof.ressi@gmx.at]>Betreff: Re: [PD] [clone]'s instance number What about having an if statement that detects clone objectand if so, compensates for $2 discrepancy and assigns $1 to it instead and increments from there? This way the discrepancy is internalized as opposed to something user needs to deal with.-- Ivica Ico Bukvic, D.M.A. Associate Professor Computer Music ICAT Senior Fellow Director -- DISIS, L2Ork Virginia Tech School of Performing Arts – 0141 Blacksburg, VA 24061 (540) 231-6139 ico@vt.edu[ico@vt.edu] www.performingarts.vt.edu[http://www.performingarts.vt.edu][http://www.performingarts.vt.edu%5Bhttp://www.performingarts.vt.edu%5D%5D%5B...]]] disis.icat.vt.edu[http://disis.icat.vt.edu][http://disis.icat.vt.edu%5Bhttp://disis.icat.vt.edu%5D%5D%5Bhttp://disis.ica...]]] l2ork.icat.vt.edu[http://l2ork.icat.vt.edu][http://l2ork.icat.vt.edu%5Bhttp://l2ork.icat.vt.edu%5D%5D%5Bhttp://l2ork.ica...]]] ico.bukvic.net[http://ico.bukvic.net][http://ico.bukvic.net%5Bhttp://ico.bukvic.net%5D%5D%5Bhttp://ico.bukvic.net%...]]]
On May 11, 2016 11:50, "Miller Puckette"<msp@ucsd.edu[msp@ucsd.edu][msp@ucsd.edu[msp@ucsd.edu]]> wrote:I gave this some thought but couldn't come up with anything more natural thanthe "$1" idea. It allows for changing the other argumentsmore easily thanit would have been if the instance number were passed last.Also, somehowit felt more natural to have the instance number first.
If there's interest in the idea, I could add arrguments tochange thebehavior (such as putting $1 last instead of first)...Offhand I doubt thatwould get used much though.
cheers Miller
On Wed, May 11, 2016 at 05:26:21PM +0200, Christof Ressiwrote:There's also a pitfall: additional creation arguments forthe cloned abstraction will start with $2.For example, in [clone 16 my-abstraction 1 5 9] '1' will beparsed as $2, '5' as $3, '9' as $4 etc.No problem, if the abstraction was written for being usedwith [clone], but bad when cloning existing abstractions. I'm wondering if there could be a way to get the abstractionID without messing up existing abstractions... Maybe have a dedicated object? For now, I think it's important to mention the parsing ofadditional creation arguments in the help file. Christof Gesendet: Mittwoch, 11. Mai 2016 um 16:25 Uhr Von: "IOhannes m zmoelnig"<zmoelnig@iem.at[zmoelnig@iem.at][zmoelnig@iem.at[zmoelnig@iem.at]]>An: pd-list@lists.iem.at[pd-list@lists.iem.at][pd-list@lists.iem.at[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 instancenumber 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[Pd-list@lists.iem.at][Pd-list@lists.iem.at[Pd-list@lists.iem.at]] mailing list UNSUBSCRIBE and account-management ->https://lists.puredata.info/listinfo/pd-list%5Bhttps://lists.puredata.info/l...]]]
Pd-list@lists.iem.at[Pd-list@lists.iem.at][Pd-list@lists.iem.at[Pd-list@lists.iem.at]] mailing list UNSUBSCRIBE and account-management ->https://lists.puredata.info/listinfo/pd-list%5Bhttps://lists.puredata.info/l...]]]
Pd-list@lists.iem.at[Pd-list@lists.iem.at][Pd-list@lists.iem.at[Pd-list@lists.iem.at]] mailing list UNSUBSCRIBE and account-management ->https://lists.puredata.info/listinfo/pd-list%5Bhttps://lists.puredata.info/l...]]]
Pd-list@lists.iem.at[Pd-list@lists.iem.at] mailing list UNSUBSCRIBE and account-management ->https://lists.puredata.info/listinfo/pd-list%5Bhttps://lists.puredata.info/l...]]
Pd-list@lists.iem.at[Pd-list@lists.iem.at] mailing list UNSUBSCRIBE and account-management ->https://lists.puredata.info/listinfo/pd-list%5Bhttps://lists.puredata.info/l...]]
Pd-list@lists.iem.at[Pd-list@lists.iem.at] mailing list UNSUBSCRIBE and account-management ->https://lists.puredata.info/listinfo/pd-list%5Bhttps://lists.puredata.info/l...]]
Pd-list@lists.iem.at[Pd-list@lists.iem.at] mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list%5Bhttps://lists.puredata.info/l...]]
Pd-list@lists.iem.at[Pd-list@lists.iem.at] mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list%5Bhttps://lists.puredata.info/l...]]
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list%5Bhttps://lists.puredata.info/l...]
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list%5Bhttps://lists.puredata.info/l...]
I've been struggling to follow this thread... Can I just confirm that you're talking about adding a new mode for [clone], but that the original behavior will remain the same? Ie. if [clone] is un-flagged, will I still be able to invoke the instance number with $1?
Date: Wed, 18 May 2016 20:01:24 -0700 From: msp@ucsd.edu To: christof.ressi@gmx.at CC: pd-list@lists.iem.at Subject: Re: [PD] [clone]'s instance number
OK... I'm talked into it. Should appear (as a "-x" optional flag) once 0.47-1 is ready.
cheers Miller
On Wed, May 18, 2016 at 11:07:36PM +0200, Christof Ressi wrote:
Do you mean something like you have 1-baz.pd, 2-baz.pd, etc. and then inside your [clone] abstraction you've got [$1-baz]? I suppose this is a potential use case.
Haha, sorry bad wording from my side, but this also an interesting use case!
I rather meant projects where everything is broken into modules which themselves contain other modules etc. The first module in the tree takes an ID as an *creation argument* and passes it down do its submodules. Something like that.
Gesendet: Mittwoch, 18. Mai 2016 um 22:40 Uhr Von: "Matt Barber" brbrofsvl@gmail.com An: "Christof Ressi" christof.ressi@gmx.at Cc: "Miller Puckette" msp@ucsd.edu, Pd-list pd-list@lists.iem.at Betreff: Re: [PD] [clone]'s instance number
BTW: I guess, it's mostly a design question, whether to work with instance numbers inside abstractions and or to work with dispatching via the inlets and outlets. However, I can think of at least two cases where it's necessary to have immediate access to instance numbers inside an abstraction: a) [send~ foo-$1] or [catch~ bar-$1] to disambiguate audio inputs/outputs, because you can't set these two dynamically like [r~] and [throw~]
Where do you envision the corresponding [r~ foo-$1] or [throw~ bar-$1] to reside? If it's in the same abstraction, then $0 ought to work just as well. b) instantiate another abstraction by the instance number (nested abstractions)
Do you mean something like you have 1-baz.pd, 2-baz.pd, etc. and then inside your [clone] abstraction you've got [$1-baz]? I suppose this is a potential use case.
So the current behaviour of [clone] (passing the instance number as $1) can be important and very useful. The alternative mode I proposed is mainly for convenience but I'm sure it would pay off in the long run!
Gesendet: Mittwoch, 18. Mai 2016 um 18:45 Uhr Von: "Miller Puckette" msp@ucsd.edu An: "Alex Norman" <x37v.alex@gmail.com[x37v.alex@gmail.com]>
Cc: "Christof Ressi" <christof.ressi@gmx.at[christof.ressi@gmx.at]>, Pd-list <pd-list@lists.iem.at[pd-list@lists.iem.at]> Betreff: Re: [PD] [clone]'s instance number
OK... sounds like it's worth putting in. I guess with the one-letter it already takes (-s) I should also add something like a -e flag to put the number argument at the end of the list instead of the beginning, or something like that.
cheers Miller
On Wed, May 18, 2016 at 07:20:29AM -0700, Alex Norman wrote:
I see your point, the abstraction need not know it's instance number since only the messages meant for it would be dispatched to it.. If you don't care about using sends directed to a specific abstraction then the $1 does nothing for you and if the flag to clone could ditch the $1 to instance setting and just set the arguments to the abstraction [clone -flag blah 20 1 2 3] makes 20 copies of blah with args $1=1 $2=2.. You could use more of your existing abstractions as is, using their args the same way with or without clone.
I'm warming up to that idea.
Alex
On May 17, 2016 6:44:51 PM PDT, Christof Ressi <christof.ressi@gmx.at[christof.ressi@gmx.at]> wrote:
you can still disambiguate, because incoming messages are dispatched by the instance number and outgoing messages are prepended with it!
My suggestion was mainly concerning all abstractions that work with inlets and outlets (as opposed to sends and receives), where you basically pass a message and get something out. This could be anything, from simple message filtering to a perlin noise generator. Or also existing audio modules that work with a message inlet. If there was such a flag, you could take any of these abstractions as they are, control them separately by prepending the instance number and route the message output (or use the sum of the audio output).
I guess, people will use [clone] mainly for voice management for synthesizers, granular synthesis, complicated nested patches etc., but I also see a great potential for massive data generation by using existing simple abstractions and cloning them.
Personally, I have many abstractions I would like to use with [clone], but either I'd have to rewrite them or make a wrapper abstraction. It's not a big deal, it's just that an alternative forwarding mode would provide some additional convenience (and could also encourage other usages for [clone]).
Anyway, I can totally live without this feature, but would be happy to have it :-).
Gesendet: Mittwoch, 18. Mai 2016 um 02:35 Uhr Von: "Miller Puckette" <msp@ucsd.edu[msp@ucsd.edu]> An: "Christof Ressi" <christof.ressi@gmx.at[christof.ressi@gmx.at]> Cc: Pd-list <pd-list@lists.iem.at[pd-list@lists.iem.at]> Betreff: Re: [PD] [clone]'s instance number
I'm not sure... would anyone ever use this feature? The patch in
question
would ahve to take arguments (if not, thre's no problem) but not use
them to
disambiguate the instances (because clone will set them all equal
anyway).
I have trouble imaginig anyone building a patch like that.
cheers Miller
On Wed, May 18, 2016 at 12:54:16AM +0200, Christof Ressi wrote: > What do you think about the idea with a flag for changing the way
creation arguments are forwarded? It would be really handy if you could write something like
> [clone -flag 100 my-abstraction 5 6 7] and $1 $2 $3 will be
substituted by 5 6 7 instead of [N] 5 6. This way you could use existing abstractions as they are, without the need for writing a wrapper abstraction to handle the creation argument forwarding.
> > Christof > > > Gesendet: Dienstag, 17. Mai 2016 um 04:05 Uhr > > Von: "Miller Puckette" <msp@ucsd.edu[msp@ucsd.edu]> > > An: "Jaime Oliver" <jaime.oliver2@gmail.com[jaime.oliver2@gmail.com]> > > Cc: "Christof Ressi" <christof.ressi@gmx.at[christof.ressi@gmx.at]>, Pd-list
<pd-list@lists.iem.at[pd-list@lists.iem.at]>
> > Betreff: Re: [PD] [clone]'s instance number > > > > Cool, taking this suggestion. At least for now it will work
either way,
> > but it's much more readable with the abstraction name first so I
changed the
> > help file to invoke it that way. > > > > cheers > > Miller > > > > On Wed, May 11, 2016 at 01:13:37PM -0400, Jaime Oliver wrote: > > > Well, > > > > > > What would happen if instead of calling clone like: > > > > > > [clone 16 my-abstraction 1 5 9] > > > > > > we called it with: > > > > > > [clone my-abstraction 16 1 5 9] > > > > > > and then $1 seems quite appropriate. > > > > > > ? > > > > > > J > > > > > > > > > > > > > On May 11, 2016, at 12:17 PM, Christof Ressi
<christof.ressi@gmx.at[christof.ressi@gmx.at]> wrote:
> > > > > > > > I agree that $1 is most natural! > > > > > > > > However, what about adding an additional flag -foo for
[clone], which changes the way creation arguments are parsed?
> > > > Passing -foo could ignore the object ID and rather forward
creation arguments just as they are.
> > > > > > > > This wouldn't break the current behaviour of [clone], but
provide some functionality to deal with ordinary abstractions more conveniently.
> > > > > > > > Christof > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Gesendet: Mittwoch, 11. Mai 2016 um 18:06 Uhr > > > > Von: "Ivica Bukvic" <ico@vt.edu[ico@vt.edu]> > > > > An: "Miller Puckette" <msp@ucsd.edu[msp@ucsd.edu]> > > > > Cc: "IOhannes m zmoelnig" <zmoelnig@iem.at[zmoelnig@iem.at]>, Pd-list
<pd-list@lists.iem.at[pd-list@lists.iem.at]>, "Christof Ressi" <christof.ressi@gmx.at[christof.ressi@gmx.at]>
> > > > Betreff: Re: [PD] [clone]'s instance number > > > > What about having an if statement that detects clone object
and if so, compensates for $2 discrepancy and assigns $1 to it instead and increments from there? This way the discrepancy is internalized as opposed to something user needs to deal with.
> > > > -- > > > > Ivica Ico Bukvic, D.M.A. > > > > Associate Professor > > > > Computer Music > > > > ICAT Senior Fellow > > > > Director -- DISIS, L2Ork > > > > Virginia Tech > > > > School of Performing Arts – 0141 > > > > Blacksburg, VA 24061 > > > > (540) 231-6139 > > > > ico@vt.edu[ico@vt.edu] > > > > www.performingarts.vt.edu[http://www.performingarts.vt.edu][http://www.performingarts.vt.edu%5Bhttp://www.performingarts.vt.edu]] > > > > disis.icat.vt.edu[http://disis.icat.vt.edu][http://disis.icat.vt.edu%5Bhttp://disis.icat.vt.edu]] > > > > l2ork.icat.vt.edu[http://l2ork.icat.vt.edu][http://l2ork.icat.vt.edu%5Bhttp://l2ork.icat.vt.edu]] > > > > ico.bukvic.net[http://ico.bukvic.net][http://ico.bukvic.net%5Bhttp://ico.bukvic.net]] > > > > > > > > On May 11, 2016 11:50, "Miller Puckette"
<msp@ucsd.edu[msp@ucsd.edu][msp@ucsd.edu[msp@ucsd.edu]]> wrote:I gave this some thought but couldn't come up with anything more natural than
> > > > the "$1" idea. It allows for changing the other arguments
more easily than
> > > > it would have been if the instance number were passed last.
Also, somehow
> > > > it felt more natural to have the instance number first. > > > > > > > > If there's interest in the idea, I could add arrguments to
change the
> > > > behavior (such as putting $1 last instead of first)...
Offhand I doubt that
> > > > would get used much though. > > > > > > > > cheers > > > > Miller > > > > > > > > > > > > > > > > On Wed, May 11, 2016 at 05:26:21PM +0200, Christof Ressi
wrote:
> > > >> 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[zmoelnig@iem.at][zmoelnig@iem.at[zmoelnig@iem.at]]>
> > > >>> An: pd-list@lists.iem.at[pd-list@lists.iem.at][pd-list@lists.iem.at[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[Pd-list@lists.iem.at][Pd-list@lists.iem.at[Pd-list@lists.iem.at]] mailing list > > > >>> UNSUBSCRIBE and account-management ->
https://lists.puredata.info/listinfo/pd-list%5Bhttps://lists.puredata.info/l...]]
> > > >>> > > > >> > > > >> _______________________________________________ > > > >> Pd-list@lists.iem.at[Pd-list@lists.iem.at][Pd-list@lists.iem.at[Pd-list@lists.iem.at]] mailing list > > > >> UNSUBSCRIBE and account-management ->
https://lists.puredata.info/listinfo/pd-list%5Bhttps://lists.puredata.info/l...]]
> > > > > > > > _______________________________________________ > > > > Pd-list@lists.iem.at[Pd-list@lists.iem.at][Pd-list@lists.iem.at[Pd-list@lists.iem.at]] mailing list > > > > UNSUBSCRIBE and account-management ->
https://lists.puredata.info/listinfo/pd-list%5Bhttps://lists.puredata.info/l...]]
> > > > > > > > _______________________________________________ > > > > Pd-list@lists.iem.at[Pd-list@lists.iem.at] mailing list > > > > UNSUBSCRIBE and account-management ->
https://lists.puredata.info/listinfo/pd-list%5Bhttps://lists.puredata.info/l...]
> > > > > > > > > _______________________________________________ > > > Pd-list@lists.iem.at[Pd-list@lists.iem.at] mailing list > > > UNSUBSCRIBE and account-management ->
https://lists.puredata.info/listinfo/pd-list%5Bhttps://lists.puredata.info/l...]
> > > > _______________________________________________ > Pd-list@lists.iem.at[Pd-list@lists.iem.at] mailing list > UNSUBSCRIBE and account-management ->
https://lists.puredata.info/listinfo/pd-list%5Bhttps://lists.puredata.info/l...]
Pd-list@lists.iem.at[Pd-list@lists.iem.at] mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list%5Bhttps://lists.puredata.info/l...]
Pd-list@lists.iem.at[Pd-list@lists.iem.at] mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list%5Bhttps://lists.puredata.info/l...]
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
Yep.
[clone z 12]
or
[clone 12 z]
(equivalent) make 12 copies of 'z' passing $1 = 0, ..., 11. But
[clone -x z 12]
makes the 12 copies of z without filling in $1.
cheers Miller
On Thu, May 19, 2016 at 06:14:00AM +0100, Liam Goodacre wrote:
I've been struggling to follow this thread... Can I just confirm that you're talking about adding a new mode for [clone], but that the original behavior will remain the same? Ie. if [clone] is un-flagged, will I still be able to invoke the instance number with $1?
Date: Wed, 18 May 2016 20:01:24 -0700 From: msp@ucsd.edu To: christof.ressi@gmx.at CC: pd-list@lists.iem.at Subject: Re: [PD] [clone]'s instance number
OK... I'm talked into it. Should appear (as a "-x" optional flag) once 0.47-1 is ready.
cheers Miller
On Wed, May 18, 2016 at 11:07:36PM +0200, Christof Ressi wrote:
Do you mean something like you have 1-baz.pd, 2-baz.pd, etc. and then inside your [clone] abstraction you've got [$1-baz]? I suppose this is a potential use case.
Haha, sorry bad wording from my side, but this also an interesting use case!
I rather meant projects where everything is broken into modules which themselves contain other modules etc. The first module in the tree takes an ID as an *creation argument* and passes it down do its submodules. Something like that.
Gesendet: Mittwoch, 18. Mai 2016 um 22:40 Uhr Von: "Matt Barber" brbrofsvl@gmail.com An: "Christof Ressi" christof.ressi@gmx.at Cc: "Miller Puckette" msp@ucsd.edu, Pd-list pd-list@lists.iem.at Betreff: Re: [PD] [clone]'s instance number
BTW: I guess, it's mostly a design question, whether to work with instance numbers inside abstractions and or to work with dispatching via the inlets and outlets. However, I can think of at least two cases where it's necessary to have immediate access to instance numbers inside an abstraction: a) [send~ foo-$1] or [catch~ bar-$1] to disambiguate audio inputs/outputs, because you can't set these two dynamically like [r~] and [throw~]
Where do you envision the corresponding [r~ foo-$1] or [throw~ bar-$1] to reside? If it's in the same abstraction, then $0 ought to work just as well. b) instantiate another abstraction by the instance number (nested abstractions)
Do you mean something like you have 1-baz.pd, 2-baz.pd, etc. and then inside your [clone] abstraction you've got [$1-baz]? I suppose this is a potential use case.
So the current behaviour of [clone] (passing the instance number as $1) can be important and very useful. The alternative mode I proposed is mainly for convenience but I'm sure it would pay off in the long run!
Gesendet: Mittwoch, 18. Mai 2016 um 18:45 Uhr Von: "Miller Puckette" msp@ucsd.edu An: "Alex Norman" <x37v.alex@gmail.com[x37v.alex@gmail.com]>
Cc: "Christof Ressi" <christof.ressi@gmx.at[christof.ressi@gmx.at]>, Pd-list <pd-list@lists.iem.at[pd-list@lists.iem.at]> Betreff: Re: [PD] [clone]'s instance number
OK... sounds like it's worth putting in. I guess with the one-letter it already takes (-s) I should also add something like a -e flag to put the number argument at the end of the list instead of the beginning, or something like that.
cheers Miller
On Wed, May 18, 2016 at 07:20:29AM -0700, Alex Norman wrote:
I see your point, the abstraction need not know it's instance number since only the messages meant for it would be dispatched to it.. If you don't care about using sends directed to a specific abstraction then the $1 does nothing for you and if the flag to clone could ditch the $1 to instance setting and just set the arguments to the abstraction [clone -flag blah 20 1 2 3] makes 20 copies of blah with args $1=1 $2=2.. You could use more of your existing abstractions as is, using their args the same way with or without clone.
I'm warming up to that idea.
Alex
On May 17, 2016 6:44:51 PM PDT, Christof Ressi <christof.ressi@gmx.at[christof.ressi@gmx.at]> wrote:
you can still disambiguate, because incoming messages are dispatched by the instance number and outgoing messages are prepended with it!
My suggestion was mainly concerning all abstractions that work with inlets and outlets (as opposed to sends and receives), where you basically pass a message and get something out. This could be anything, from simple message filtering to a perlin noise generator. Or also existing audio modules that work with a message inlet. If there was such a flag, you could take any of these abstractions as they are, control them separately by prepending the instance number and route the message output (or use the sum of the audio output).
I guess, people will use [clone] mainly for voice management for synthesizers, granular synthesis, complicated nested patches etc., but I also see a great potential for massive data generation by using existing simple abstractions and cloning them.
Personally, I have many abstractions I would like to use with [clone], but either I'd have to rewrite them or make a wrapper abstraction. It's not a big deal, it's just that an alternative forwarding mode would provide some additional convenience (and could also encourage other usages for [clone]).
Anyway, I can totally live without this feature, but would be happy to have it :-).
> Gesendet: Mittwoch, 18. Mai 2016 um 02:35 Uhr > Von: "Miller Puckette" <msp@ucsd.edu[msp@ucsd.edu]> > An: "Christof Ressi" <christof.ressi@gmx.at[christof.ressi@gmx.at]> > Cc: Pd-list <pd-list@lists.iem.at[pd-list@lists.iem.at]> > Betreff: Re: [PD] [clone]'s instance number > > I'm not sure... would anyone ever use this feature? The patch in question > would ahve to take arguments (if not, thre's no problem) but not use them to > disambiguate the instances (because clone will set them all equal anyway). > I have trouble imaginig anyone building a patch like that. > > cheers > Miller > > On Wed, May 18, 2016 at 12:54:16AM +0200, Christof Ressi wrote: > > What do you think about the idea with a flag for changing the way creation arguments are forwarded? It would be really handy if you could write something like > > [clone -flag 100 my-abstraction 5 6 7] and $1 $2 $3 will be substituted by 5 6 7 instead of [N] 5 6. This way you could use existing abstractions as they are, without the need for writing a wrapper abstraction to handle the creation argument forwarding. > > > > Christof > > > > > Gesendet: Dienstag, 17. Mai 2016 um 04:05 Uhr > > > Von: "Miller Puckette" <msp@ucsd.edu[msp@ucsd.edu]> > > > An: "Jaime Oliver" <jaime.oliver2@gmail.com[jaime.oliver2@gmail.com]> > > > Cc: "Christof Ressi" <christof.ressi@gmx.at[christof.ressi@gmx.at]>, Pd-list <pd-list@lists.iem.at[pd-list@lists.iem.at]> > > > Betreff: Re: [PD] [clone]'s instance number > > > > > > Cool, taking this suggestion. At least for now it will work either way, > > > but it's much more readable with the abstraction name first so I changed the > > > help file to invoke it that way. > > > > > > cheers > > > Miller > > > > > > On Wed, May 11, 2016 at 01:13:37PM -0400, Jaime Oliver wrote: > > > > Well, > > > > > > > > What would happen if instead of calling clone like: > > > > > > > > [clone 16 my-abstraction 1 5 9] > > > > > > > > we called it with: > > > > > > > > [clone my-abstraction 16 1 5 9] > > > > > > > > and then $1 seems quite appropriate. > > > > > > > > ? > > > > > > > > J > > > > > > > > > > > > > > > > > On May 11, 2016, at 12:17 PM, Christof Ressi <christof.ressi@gmx.at[christof.ressi@gmx.at]> wrote: > > > > > > > > > > I agree that $1 is most natural! > > > > > > > > > > However, what about adding an additional flag -foo for [clone], which changes the way creation arguments are parsed? > > > > > Passing -foo could ignore the object ID and rather forward creation arguments just as they are. > > > > > > > > > > This wouldn't break the current behaviour of [clone], but provide some functionality to deal with ordinary abstractions more conveniently. > > > > > > > > > > Christof > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Gesendet: Mittwoch, 11. Mai 2016 um 18:06 Uhr > > > > > Von: "Ivica Bukvic" <ico@vt.edu[ico@vt.edu]> > > > > > An: "Miller Puckette" <msp@ucsd.edu[msp@ucsd.edu]> > > > > > Cc: "IOhannes m zmoelnig" <zmoelnig@iem.at[zmoelnig@iem.at]>, Pd-list <pd-list@lists.iem.at[pd-list@lists.iem.at]>, "Christof Ressi" <christof.ressi@gmx.at[christof.ressi@gmx.at]> > > > > > Betreff: Re: [PD] [clone]'s instance number > > > > > What about having an if statement that detects clone object and if so, compensates for $2 discrepancy and assigns $1 to it instead and increments from there? This way the discrepancy is internalized as opposed to something user needs to deal with. > > > > > -- > > > > > Ivica Ico Bukvic, D.M.A. > > > > > Associate Professor > > > > > Computer Music > > > > > ICAT Senior Fellow > > > > > Director -- DISIS, L2Ork > > > > > Virginia Tech > > > > > School of Performing Arts – 0141 > > > > > Blacksburg, VA 24061 > > > > > (540) 231-6139 > > > > > ico@vt.edu[ico@vt.edu] > > > > > www.performingarts.vt.edu[http://www.performingarts.vt.edu][http://www.performingarts.vt.edu%5Bhttp://www.performingarts.vt.edu]] > > > > > disis.icat.vt.edu[http://disis.icat.vt.edu][http://disis.icat.vt.edu%5Bhttp://disis.icat.vt.edu]] > > > > > l2ork.icat.vt.edu[http://l2ork.icat.vt.edu][http://l2ork.icat.vt.edu%5Bhttp://l2ork.icat.vt.edu]] > > > > > ico.bukvic.net[http://ico.bukvic.net][http://ico.bukvic.net%5Bhttp://ico.bukvic.net]] > > > > > > > > > > On May 11, 2016 11:50, "Miller Puckette" <msp@ucsd.edu[msp@ucsd.edu][msp@ucsd.edu[msp@ucsd.edu]]> wrote:I gave this some thought but couldn't come up with anything more natural than > > > > > the "$1" idea. It allows for changing the other arguments more easily than > > > > > it would have been if the instance number were passed last. Also, somehow > > > > > it felt more natural to have the instance number first. > > > > > > > > > > If there's interest in the idea, I could add arrguments to change the > > > > > behavior (such as putting $1 last instead of first)... Offhand I doubt that > > > > > would get used much though. > > > > > > > > > > cheers > > > > > Miller > > > > > > > > > > > > > > > > > > > > On Wed, May 11, 2016 at 05:26:21PM +0200, Christof Ressi wrote: > > > > >> 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[zmoelnig@iem.at][zmoelnig@iem.at[zmoelnig@iem.at]]> > > > > >>> An: pd-list@lists.iem.at[pd-list@lists.iem.at][pd-list@lists.iem.at[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[Pd-list@lists.iem.at][Pd-list@lists.iem.at[Pd-list@lists.iem.at]] mailing list > > > > >>> UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list%5Bhttps://lists.puredata.info/l...]] > > > > >>> > > > > >> > > > > >> _______________________________________________ > > > > >> Pd-list@lists.iem.at[Pd-list@lists.iem.at][Pd-list@lists.iem.at[Pd-list@lists.iem.at]] mailing list > > > > >> UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list%5Bhttps://lists.puredata.info/l...]] > > > > > > > > > > _______________________________________________ > > > > > Pd-list@lists.iem.at[Pd-list@lists.iem.at][Pd-list@lists.iem.at[Pd-list@lists.iem.at]] mailing list > > > > > UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list%5Bhttps://lists.puredata.info/l...]] > > > > > > > > > > _______________________________________________ > > > > > Pd-list@lists.iem.at[Pd-list@lists.iem.at] mailing list > > > > > UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list%5Bhttps://lists.puredata.info/l...] > > > > > > > > > > > > _______________________________________________ > > > > Pd-list@lists.iem.at[Pd-list@lists.iem.at] mailing list > > > > UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list%5Bhttps://lists.puredata.info/l...] > > > > > > > _______________________________________________ > > Pd-list@lists.iem.at[Pd-list@lists.iem.at] mailing list > > UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list%5Bhttps://lists.puredata.info/l...] >
Pd-list@lists.iem.at[Pd-list@lists.iem.at] mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list%5Bhttps://lists.puredata.info/l...]
Pd-list@lists.iem.at[Pd-list@lists.iem.at] mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list%5Bhttps://lists.puredata.info/l...]
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
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
-
Alex -
Alex Norman
-
Christof Ressi -
IOhannes m zmoelnig -
Ivica Bukvic -
Jaime Oliver -
Liam Goodacre -
Matt Barber -
Miller Puckette