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

[Antoine Rousseau]

I think the proposal join~/split~ is the one I prefer.
It follows quite well the naming of other pairs like throw~/catch~ or
send~/receive~.
Just a personal feeling...

Antoine


Le mar. 24 janv. 2023 à 08:25, Matt Barber <brbrofsvl at gmail.com> a écrit :

> I was also going to suggest snake~ as the accepted hardware metaphor. I
> think it would maybe be snake~ and breakout~ if taken literally.
>
> In order to make in/out clear, it might be insnake~ outsnake~
>
>
> bundle~ unbundle~ would also be an intuitive choice.
>
> Whatever it ends up being, I think there definitely needs to be a visual
> clue that the connection is multichannel, and maybe to reveal the number of
> channels on hover in edit mode for clarity and debugging (especially in
> deep patch nesting)
>
> On Mon, Jan 23, 2023, 4:54 PM Alexandre Torres Porres <porres at gmail.com>
> wrote:
>
>> I find snake~ and unsafe~ a bit weird but amusing, I kinda like idea of
>> typing that object name and read it in a patch
>>
>> On Mon, 23 Jan 2023 at 18:49 Miller Puckette <msp at ucsd.edu> wrote:
>>
>>> How about "snake~ in" and "snake~ out" ... assuming a "snake" is easily
>>> enough understood as a multichannel audio cable?
>>>
>>> Or tosnake~ / fromsnake~ or even snake~ and unsnake~ ?
>>>
>>> cheers
>>> M
>>>
>>> On Mon, Jan 23, 2023 at 09:02:33AM -0300, Alexandre Torres Porres wrote:
>>> > 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://urldefense.com/v3/__https://lists.puredata.info/listinfo/pd-dev__;!!Mih3wA!FiLq_YDUBYda6b---jre9DEKXbAOKoHQN8RElivzd1cjtYcN1BN4iAg_OvfczMaP7N7QraScCw$
>>> > >
>>>
>>> > _______________________________________________
>>> > Pd-dev mailing list
>>> > Pd-dev at lists.iem.at
>>> >
>>> https://urldefense.com/v3/__https://lists.puredata.info/listinfo/pd-dev__;!!Mih3wA!FiLq_YDUBYda6b---jre9DEKXbAOKoHQN8RElivzd1cjtYcN1BN4iAg_OvfczMaP7N7QraScCw$
>>>
>>> _______________________________________________
>> Pd-dev mailing list
>> Pd-dev at lists.iem.at
>> https://lists.puredata.info/listinfo/pd-dev
>>
> _______________________________________________
> 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/20230124/e40798c4/attachment.htm>