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 <[email protected]> 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 < > > [email protected]> 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 < > > > [email protected]> 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 > > >> [email protected] > > >> > https://urldefense.com/v3/__https://lists.puredata.info/listinfo/pd-dev__;!!Mih3wA!AIiqaTwRyz8ZinhZnaqsDtZZKkLUI2Yd0FhscvBpV_g0tpivh8FmV0bmqAPnOBvfUse_Y9ql_Q$ > > >> > > > >
_______________________________________________ Pd-dev mailing list [email protected] https://lists.puredata.info/listinfo/pd-dev
