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

[José de Abreu]

sorry for double posting, but for my idea to work i think [inlet~] should
receive an outlet that gives the number of channels, this makes trivial to
then update [nop~] to give the functionality i mentioned

Em ter., 24 de jan. de 2023 07:20, José de Abreu <abreubacelar at gmail.com>
escreveu:

> 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/c03074a1/attachment-0001.htm>