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 <m...@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.re...@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" <m...@ucsd.edu> >>>> An: "Christof Ressi" <christof.re...@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" <m...@ucsd.edu> >>>>>> An: "Jaime Oliver" <jaime.oliv...@gmail.com> >>>>>> Cc: "Christof Ressi" <christof.re...@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.re...@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" <i...@vt.edu> >>>>>>>> An: "Miller Puckette" <m...@ucsd.edu> >>>>>>>> Cc: "IOhannes m zmoelnig" <zmoel...@iem.at>, Pd-list >>> <pd-list@lists.iem.at>, "Christof Ressi" <christof.re...@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 >>>>>>>> i...@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" >>> <m...@ucsd.edu[m...@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" >>> <zmoel...@iem.at[zmoel...@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[https://lists.puredata.info/listinfo/pd-list] >>>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> Pd-list@lists.iem.at[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[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 >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> 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
