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 <[email protected]> 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 <[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
