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
