[PD-dev] pack~/unpack~ (was Re: multichannel signals, preliminary support)

[Alexandre Torres Porres]

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

Em seg., 23 de jan. de 2023 às 06:38, Roman Haefeli <reduzent at gmail.com>
escreveu:

> On Mon, 2023-01-23 at 08:40 +0100, IOhannes m zmoelnig wrote:
> >
> > i would prefer this.
> > howe about the [split~]/[merge~] pair suggested by Jean-Yves?
>
> I think those are more descriptive names, regardless of the name
> collision problem.
>
> + 1
>
> > in retrospect i wouldn't have named the zexy objects like i did, but
> > i
> > was young and needed the money.
>
> I don't think 'pack~' and 'unpack~' fit any less to what zexy's objects
> do. Like their non-tilde counterparts, they pack to lists und unpack
> from lists. I think those names are quite good.
>
> Roman
>
> _______________________________________________
> Pd-dev mailing list
> Pd-dev at lists.iem.at
> https://lists.puredata.info/listinfo/pd-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-dev/attachments/20230123/0d0c0b37/attachment.htm>