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