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