[PD-dev] multichannel signals, preliminary support

[IOhannes m zmoelnig]

On 1/19/23 07:02, Alexandre Torres Porres wrote:
> 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.

i'm not actually sure i can follow your problems here.
how would an [mc~] wrapper make live any simpler than [clone]?

could you please rephrase your elaborate examples for decaffeinated 5 
year old with concrete examples?

e.g. you are saying that for creating a multichannel aware [dac~]:
 > In clone, I need a damn simple abstraction with [inlet~] going into
 > [dac~ $1]

so afaict the idea is to get rid of this abstraction altogether, and be 
able to just use
[clone -di -s 1 dac~ 16]


so you give a counter-example (instead of the "special-case [dac~]"):
 > 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.

again, i don't see why we couldn't juse use
[clone -x -d lop~ 500]

how could that be different from your [mc~]? (well: apart from having to 
remember the actual incantation)


mgfadsr
IOhannes
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 840 bytes
Desc: OpenPGP digital signature
URL: <http://lists.puredata.info/pipermail/pd-dev/attachments/20230119/85e3f5f8/attachment.sig>