<div dir="ltr">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~<div><br></div><div>My idea is that the object could just see how many channels there are in the multichannel array and deal with it.</div><div><br></div><div>Another question is how to deal with this in externals :) </div><div><br></div><div>cheers </div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Em ter., 17 de jan. de 2023 às 01:30, Alexandre Torres Porres <<a href="mailto:porres@gmail.com">porres@gmail.com</a>> escreveu:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>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.</div><div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Em ter., 17 de jan. de 2023 às 00:24, Miller Puckette via Pd-dev <<a href="mailto:pd-dev@lists.iem.at" target="_blank">pd-dev@lists.iem.at</a>> escreveu:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">To Pd dev -<br>
<br>
I've pushed what I think is working support for multichannel signals.  Many<br>
objects haven't yet been adapted to deal with them, but there are enough to<br>
at least test the concepts: lop~, send~, receive~, and (ugh) clone are<br>
multichannel-aware, and new pack~ and unpack~ objects are provided to<br>
combine and split signal channels.<br>
<br>
I've put a couple of example patches on<br>
<a href="http://msp.ucsd.edu/tmp/multichannel-tests.tgz" rel="noreferrer" target="_blank">http://msp.ucsd.edu/tmp/multichannel-tests.tgz</a><br>
... the interplay between multichannel inlets and outlets and clone<br>
are sometimes amusing.<br>
<br>
cheers<br>
Miller<br>
<br>
<br>
<br>
_______________________________________________<br>
Pd-dev mailing list<br>
<a href="mailto:Pd-dev@lists.iem.at" target="_blank">Pd-dev@lists.iem.at</a><br>
<a href="https://lists.puredata.info/listinfo/pd-dev" rel="noreferrer" target="_blank">https://lists.puredata.info/listinfo/pd-dev</a><br>
</blockquote></div>
</blockquote></div>