Now, as I see, [send~] and [receive~] need an extra argument to set the number of channels. I wonder if all objects will end up having arguments or if you just think this is a nice feature for s~/r~

My idea is that the object could just see how many channels there are in the multichannel array and deal with it.

Another question is how to deal with this in externals :) 

cheers 

Em ter., 17 de jan. de 2023 às 01:30, Alexandre Torres Porres <porres@gmail.com> escreveu:
Wow, [clone]'s nem multichannel functionalities are quite cool and amusing indeed. I always wanted to be able to have [clone] output parallel processing - like having white noise being filtered in parallel with a filterbank and then having access to each output instead of the sum. This finally makes it happen with the '-d' flag, which is amazing! But in order to do this I have to copy a single input into a multichannel array with [pack~] and I wonder if this can be simplified by using yet a new flag where a single signal inlet~ can be distributed to all copies and a multichannel is output. Maybe not worth the hassle, but maybe it could be more significantly efficient? If it's not significantly efficient then it would be just a bit more convenient.

Em ter., 17 de jan. de 2023 às 00:24, Miller Puckette via Pd-dev <pd-dev@lists.iem.at> escreveu:
To Pd dev -

I've pushed what I think is working support for multichannel signals.  Many
objects haven't yet been adapted to deal with them, but there are enough to
at least test the concepts: lop~, send~, receive~, and (ugh) clone are
multichannel-aware, and new pack~ and unpack~ objects are provided to
combine and split signal channels.

I've put a couple of example patches on
http://msp.ucsd.edu/tmp/multichannel-tests.tgz
... the interplay between multichannel inlets and outlets and clone
are sometimes amusing.

cheers
Miller



_______________________________________________
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev