[PD-dev] multichannel signals, preliminary support

Miller Puckette msp at ucsd.edu
Tue Jan 17 17:18:25 CET 2023


It turned out that having send~/receive~ detect channel counts would have
necessitated replacing the whole ugen sorting system with a two-pass one,
so that when each is scheduled it can find out about the corresponding
ones.  So it was too heavy a chenge to pull off.

The same will be true for catch~/throw~.  Also, if it's ever desirable
for clone~ to distribute/repack things in chunks of more than one
channel at a time, I guess inlet~/outlet~ will need channel arguments
too.  But I doubt there will be enough demand to justify doing that.

cheers
M
On Tue, Jan 17, 2023 at 01:33:50AM -0300, Alexandre Torres Porres wrote:
> 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 at 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 at 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 at lists.iem.at
> >> https://urldefense.com/v3/__https://lists.puredata.info/listinfo/pd-dev__;!!Mih3wA!AIiqaTwRyz8ZinhZnaqsDtZZKkLUI2Yd0FhscvBpV_g0tpivh8FmV0bmqAPnOBvfUse_Y9ql_Q$ 
> >>
> >





More information about the Pd-dev mailing list