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 <[email protected]> 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 <[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
