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 <[email protected]> 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 <[email protected]> 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 <[email protected]> >> 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 <[email protected]> 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 < >>>> [email protected]> >>>> > 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 >>>> > > [email protected] >>>> > > >>>> https://urldefense.com/v3/__https://lists.puredata.info/listinfo/pd-dev__;!!Mih3wA!FiLq_YDUBYda6b---jre9DEKXbAOKoHQN8RElivzd1cjtYcN1BN4iAg_OvfczMaP7N7QraScCw$ >>>> > > >>>> >>>> > _______________________________________________ >>>> > Pd-dev mailing list >>>> > [email protected] >>>> > >>>> https://urldefense.com/v3/__https://lists.puredata.info/listinfo/pd-dev__;!!Mih3wA!FiLq_YDUBYda6b---jre9DEKXbAOKoHQN8RElivzd1cjtYcN1BN4iAg_OvfczMaP7N7QraScCw$ >>>> >>>> _______________________________________________ >>> Pd-dev mailing list >>> [email protected] >>> https://lists.puredata.info/listinfo/pd-dev >>> >> _______________________________________________ >> Pd-dev mailing list >> [email protected] >> https://lists.puredata.info/listinfo/pd-dev >> > _______________________________________________ > Pd-dev mailing list > [email protected] > https://lists.puredata.info/listinfo/pd-dev >
_______________________________________________ Pd-dev mailing list [email protected] https://lists.puredata.info/listinfo/pd-dev
