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@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@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@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@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@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@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@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@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@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev
_______________________________________________
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev
_______________________________________________
Pd-dev mailing list
Pd-dev@lists.iem.at
https://lists.puredata.info/listinfo/pd-dev