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 <[email protected]> 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 <[email protected]> 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 <[email protected]> >> 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" <[email protected]> >>>> An: "Christof Ressi" <[email protected]> >>>> Cc: Pd-list <[email protected]> >>>> 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" <[email protected]> >>>>>> An: "Jaime >>>>>> Oliver" <[email protected]> >>>>>> Cc: "Christof Ressi" <[email protected]>, Pd-list >>>>>> <[email protected]> >>>>>> 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 <[email protected]> >>>>>>> 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" <[email protected]> >>>>>>>> An: "Miller Puckette" <[email protected]> >>>>>>>> Cc: "IOhannes m zmoelnig" <[email protected]>, Pd-list >>>>>>>> <[email protected]>, "Christof Ressi" <[email protected]> >>>>>>>> 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 >>>>>>>> [email protected] >>>>>>>> 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" >>>>>>>> <[email protected][[email protected]]> 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" <[email protected][[email protected]]> >>>>>>>>>> An: [email protected][[email protected]] >>>>>>>>>> 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 >>>>>>>>>> >>>>>>>>>> ------------------------------ >>>>>>>>>> >>>>>>>>>> [email protected][[email protected]] mailing list >>>>>>>>>> UNSUBSCRIBE and account-management -> >>>>>>>>>> https://lists.puredata.info/listinfo/pd-list[https://lists.puredata.info/listinfo/pd-list] >>>>>>>>>> >>>>>>>>>> >>>>>>>>> ------------------------------ >>>>>>>>> >>>>>>>>> [email protected][[email protected]] mailing list >>>>>>>>> UNSUBSCRIBE and account-management -> >>>>>>>>> https://lists.puredata.info/listinfo/pd-list[https://lists.puredata.info/listinfo/pd-list] >>>>>>>>> >>>>>>>> >>>>>>>> ------------------------------ >>>>>>>> >>>>>>>> [email protected][[email protected]] mailing list >>>>>>>> UNSUBSCRIBE and account-management -> >>>>>>>> https://lists.puredata.info/listinfo/pd-list[https://lists.puredata.info/listinfo/pd-list] >>>>>>>> >>>>>>>> ------------------------------ >>>>>>>> >>>>>>>> [email protected] mailing list >>>>>>>> UNSUBSCRIBE and account-management -> >>>>>>>> https://lists.puredata.info/listinfo/pd-list >>>>>>>> >>>>>>> >>>>>>> >>>>>>> ------------------------------ >>>>>>> >>>>>>> [email protected] mailing list >>>>>>> UNSUBSCRIBE and account-management -> >>>>>>> https://lists.puredata.info/listinfo/pd-list >>>>>>> >>>>>> >>>>>> >>>>> ------------------------------ >>>>> >>>>> [email protected] mailing list >>>>> UNSUBSCRIBE and account-management -> >>>>> https://lists.puredata.info/listinfo/pd-list >>>>> >>>> >>>> >>> ------------------------------ >>> >>> [email protected] mailing list >>> UNSUBSCRIBE and account-management -> >>> https://lists.puredata.info/listinfo/pd-list >>> >>> >> _______________________________________________ >> [email protected] mailing list >> UNSUBSCRIBE and account-management -> >> https://lists.puredata.info/listinfo/pd-list >> >> >
_______________________________________________ [email protected] mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
