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

[José de Abreu]

About the debugging suggestion, what about enhancing [nop~] to became graph
on parent with one number box showing the number of channels?

this way we can select a connection and do Ctrl + t (triggerize) and get a
[nop~] showing a number box inside

it of course needs to show its name, so we can edit [nop~] to create
another object if needed, but as a fast way to know the number of
connections i think it would be an interesting user experience

Em ter., 24 de jan. de 2023 06:17, Antoine Rousseau <antoine at metalu.net>
escreveu:

> 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
>>
> _______________________________________________
> 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/03e14f42/attachment.htm>