[PD-dev] multichannel signals, preliminary support

[Alexandre Torres Porres]

I see there will not be a rule then on having to specify number of channels
in all objects.

Well, I don't use MAX and haven't checked their multi channel stuff in
depth, but I guess "all" MSP objects have this support if called with
"mc.", and there's a different help patch for, say, [lores~] and
[mc.lores~]. I find this all a bit confusing and more complex than ideally.

Am I right to expect we'll just add multichannel support for all vanilla
objects without having to worry about such complexity of adding a similar
different creator/help files?

And it's fine if some objects need or would benefit with specifying number
of channels, but may I propose we use a '-mc' flag for that? I'm thinking
that maybe adding this extra argument to some object might be problematic
(it wasn't with s~/r~) and better suited as a flag. Then, just for the sake
of consistency, using '-mc' for all is better.

I can think of something like [osc~ -mc 4] which creates 4 channels and
takes a multichannel signal to control the frequency of each oscillator. We
can then also provide frequencies for all channels as arguments after the
flag as well, like [osc~ -mc 4 400 500 600 700]. This would be very hard
without a '-mc' flag.

cheers

Em ter., 17 de jan. de 2023 às 13:18, Miller Puckette <msp at ucsd.edu>
escreveu:

> 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$
> > >>
> > >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-dev/attachments/20230117/869aa6a8/attachment.htm>