[PD-dev] multichannel signals, preliminary support

[Alexandre Torres Porres]

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 <danomatika at 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 <porres at gmail.com>
> wrote:
>
> Em qua., 18 de jan. de 2023 às 05:18, Dan Wilcox <danomatika at 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 <http://twitter.com/danomatika>
> danomatika.com
> robotcowboy.com
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-dev/attachments/20230119/d4122f21/attachment.htm>