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@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@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://urldefense.com/v3/__https://lists.puredata.info/listinfo/pd-dev__;!!...