> 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.oliv...@gmail.com > <mailto:jaime.oliv...@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 <m...@ucsd.edu > > <mailto: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 > >> <mailto: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 <mailto:m...@ucsd.edu>> > >>>> An: "Christof Ressi" <christof.re...@gmx.at > >>>> <mailto:christof.re...@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" <m...@ucsd.edu <mailto:m...@ucsd.edu>> > >>>>>> An: "Jaime Oliver" <jaime.oliv...@gmail.com > >>>>>> <mailto:jaime.oliv...@gmail.com>> > >>>>>> Cc: "Christof Ressi" <christof.re...@gmx.at > >>>>>> <mailto:christof.re...@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.re...@gmx.at <mailto: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 <mailto:i...@vt.edu>> > >>>>>>>> An: "Miller Puckette" <m...@ucsd.edu <mailto:m...@ucsd.edu>> > >>>>>>>> Cc: "IOhannes m zmoelnig" <zmoel...@iem.at > >>>>>>>> <mailto:zmoel...@iem.at>>, Pd-list > >>> <pd-list@lists.iem.at <mailto:pd-list@lists.iem.at>>, "Christof Ressi" > >>> <christof.re...@gmx.at <mailto: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 <tel:%28540%29%20231-6139> > >>>>>>>> i...@vt.edu <mailto:i...@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" > >>> <m...@ucsd.edu <mailto:m...@ucsd.edu>[m...@ucsd.edu > >>> <mailto: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 <mailto:zmoel...@iem.at>[zmoel...@iem.at > >>> <mailto:zmoel...@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[https://lists.puredata.info/listinfo/pd-list] > >>> > >>> <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[https://lists.puredata.info/listinfo/pd-list] > >>> > >>> <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[https://lists.puredata.info/listinfo/pd-list] > >>> > >>> <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> > >
_______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
