Without reading your reply in depth, it calls to mind my feeling that it would be *nice* if somehow clone supported subpatches natively to avoid requiring abstractions for simple things ala:
[clone pd …] This is probably another discussion, however. enohp ym morf tnes ----------- Dan Wilcox danomatika.com robotcowboy.com > On Jan 19, 2023, at 7:02 AM, Alexandre Torres Porres <por...@gmail.com> wrote: > > > but anyway, I have a few doubts how [clone] would deal with internals, and > this is just a rough idea so far, and we'll have to better discuss this when > time is right... > > for instance, how would someone deal with arguments? > > Like, I made a simple abstraction to mimic somewhat MAX's [mc.dac~], which > takes multichannel signals and distributes them from channel 1. > > In clone, I need a damn simple abstraction with [inlet~] going into [dac~ > $1], and I use the '-di' flag to distribute multichannel input and '-s 1' so > '$1' gets values starting from 1. It works great, I also have an argument in > [clone] for the number of abstractions that in this case represents maximum > channels. > > So, being able to call internal objects inside [clone] saves us the need to > write a simple abstraction for this or any other object, which is good, but > how would I be able to set the argument of [dac~] in [clone] and have it > receive the instance number? That's something to think about, because simply > calling "dac~" instead of an abstraction name doesn't or shouldn't do it. > > Now, I can and will gladly code an abstraction that mimics MAX's [mc.dac~] in > ELSE (actually I have already, just to test these things). The abstraction > uses [clone] internally and uses yet another abstraction with [dac~] inside, > so the user just needs to call the abstraction name. With what we have, > someone can make a library with all internals and whatever more externals > they like in a similar fashion. It's great that the doors are opened for this > and that we can go crazy. It would also be nice that we didn't have to worry > about this and have our "wrapper object". If not into [clone], maybe a new > object, why not call it [mc~]? I think such a new object is needed because > it might be hard to expand [clone] to do more things than it's doing. this > [mc~] object than takes object names as an argument, and further arguments > according to the objects argument. This [mc~] object would be similar to > [clone] and create inlets/outlets according to the given object name and we'd > have a way to use them to set all copies or each of them. > Maybe "mc.dac~" is a special case... let's think of a [lop~] object, we > wouldn't really need to specify "$1" as an argument... it doesn't make much > sense. It does make sense to maybe use a cutoff argument for all copies > though, so you could have [mc~ lop~ 500] and all signal inputs get filter at > 500hz. For [dac~], the special case, we could give it $1 as an argument and > it would mean instance number, and a similar flag '-s 1' could set it, so > we'd have [mc~ -s 1 dac~ $1]. > > well, I guess that's it, I'm tired and going to bed > > cheers and good night > > >> Em qua., 18 de jan. de 2023 às 11:45, Dan Wilcox <danomat...@gmail.com> >> escreveu: >> I can't answer you as I haven't looked at Miller's implementation. I can >> *imagine* that if [clone] is able to load an internal class then it follows >> it would be able to open an external class which is loaded. I didn't mean to >> imply that it can *now* but more than it *might* be able to if it can loaded >> internal objects. >> >>> On Jan 18, 2023, at 3:43 PM, Alexandre Torres Porres <por...@gmail.com> >>> wrote: >>> >>>> Em qua., 18 de jan. de 2023 às 05:18, Dan Wilcox <danomat...@gmail.com> >>>> escreveu: >>> >>>> Also similar to Miller's approach, there appears to be a way to load >>>> existing mono externals in the mc mechanism. So yeah, same problem, >>>> similar technical solution, different implementation. >>> >>> Hmm, I am still missing what is Pd's approach to load an existing external >>> into a mc mechanism... >>> >>> I'm understanding that [clone] may be able to load internal objects (and >>> abstractions of course) into a new multi-channel paradigm, but not >>> externals. Please enlighten me. >>> >>> cheers >> >> -------- >> Dan Wilcox >> @danomatika >> danomatika.com >> robotcowboy.com >> >> >>
_______________________________________________ Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
