[PD-dev] multichannel signals, preliminary support

[Miller Puckette]

So far all I'm thinking of is to make "+~" etc. be multichannel but leave
the rest (the ones that have internal state) as single-channel only.

The trouble with multichannel osc~ (etc.) is to figure out how to distribute
messages setting frequency and phase, etc., to the individual copies.

In any case, I'd consider adding the possibility for the clone object to
take the name of a primitive object (as opposed to a subpatch) - IF it's
possible to design it well and simply.  I wouldn't want to invent separate
"mc~" versions of everything - that would be a nightmare.

cheers
Miller

On Tue, Jan 17, 2023 at 02:30:44PM -0300, Alexandre Torres Porres wrote:
> 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$
> > > >>
> > > >
> >