Another option is an object like [clone] which instantiates for multichannel handling only... could simply be called [mc~] and take specific creation names for functionality, otherwise creates the objects for mc handling, so works like [text] etc:
[mc 4 osc~] -> creates 4 [osc~] instances inside [mc pack 4] -> unpacks 4 channels [mc unpack] -> packs 4 channels [mc tap 1] -> taps single channel 1 out of the 4 channels ... > On Jan 23, 2023, at 6:33 PM, [email protected] wrote: > > Message: 1 > Date: Mon, 23 Jan 2023 09:02:33 -0300 > From: Alexandre Torres Porres <[email protected] <mailto:[email protected]>> > To: Roman Haefeli <[email protected] <mailto:[email protected]>> > Cc: [email protected] <mailto:[email protected]> > Subject: Re: [PD-dev] pack~/unpack~ (was Re: multichannel signals, > preliminary support) > Message-ID: > <caeasfmiwcapqn-4luijlmkt3kdvvpzliqsuqk4w4mtzd657...@mail.gmail.com > <mailto:caeasfmiwcapqn-4luijlmkt3kdvvpzliqsuqk4w4mtzd657...@mail.gmail.com>> > Content-Type: text/plain; charset="utf-8" > > I actually do like pack~/unpack~ a lot, because they have control > counterparts and also MAX uses something similar but prepends 'mc.' to it, > so [mc.pack~] and [mc.unpack~] are exactly what [pack~] and [unpack~] do! > > On the other hand, if we really want to avoid this collision badly, maybe > we could use a similar convention to specify an object that is multichannel > aware, something quite new in the pd world. I'm not saying we should use > the same 'mc.' convention. I know using "." is not much common in the Pd > world, but in ELSE I use it and have plans to add many multichannel aware > externals that would make things simpler and while we don't have our > [clone] solution for internal and external objects, like a muti channel > [dac~] object called [dac.mc~]. I like it better that the mc comes later as > objects would be alphabetically next to their multichannel version. This > would also prevent people from thinking it's an external from Cyclone that > mimics the original. > > > So... what about [pack.mc~] and [unpack.mc~]? > > maybe just [packmc~] and [unpackmc~] as well... but I like "." > > cheers -------- Dan Wilcox @danomatika <http://twitter.com/danomatika> danomatika.com <http://danomatika.com/> robotcowboy.com <http://robotcowboy.com/>
_______________________________________________ Pd-dev mailing list [email protected] https://lists.puredata.info/listinfo/pd-dev
