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

[Dan Wilcox]

Max (I think) had the suggestion of using established audio tech terms -> [snake~] and [breakout~] where "breakout" refers to a breakout box from a physical audio snake. It might translate a bit better than a non-word like "unsnake" ?

You could take it further to [breakin~] / [breakout~] but I don't believe "breakin" is really used in the audio context, at least the part hat I deal with.

For a single channel, [tap~] makes conceptual sense to me but then this is perhaps a different (water) metaphor?

No matter what is chosen, it's nice to go through the options a this is one of these parts of the API that can't be (easily) changed later on. For my own projects, I offend agonize over the naming at the beginning.

> On Jan 25, 2023, at 7:53 AM, pd-dev-request at lists.iem.at wrote:
> 
> Message: 3
> Date: Tue, 24 Jan 2023 20:48:52 -0800
> From: Miller Puckette <msp at ucsd.edu <mailto:msp at ucsd.edu>>
> To: Christof Ressi <info at christofressi.com <mailto:info at christofressi.com>>
> Cc: pd-dev at lists.iem.at <mailto:pd-dev at lists.iem.at>
> Subject: Re: [PD-dev] pack~/unpack~ (was Re: multichannel signals,
> 	preliminary support)
> Message-ID: <Y9C0tCTVCxWeMaqd at ucsd.edu <mailto:Y9C0tCTVCxWeMaqd at ucsd.edu>>
> Content-Type: text/plain; charset=iso-8859-1
> 
> OK... now I'm hesitating between "snake~ in", "snake~ out" and "snake~ tap"
> or "join~", "split~", and "tap~"...
> 
> Former is more colorful (and crowds the namespace less).  Latter might be
> easier for non-native English speakers to deal with?
> 
> cheers
> Miller

--------
Dan Wilcox
@danomatika <http://twitter.com/danomatika>
danomatika.com <http://danomatika.com/>
robotcowboy.com <http://robotcowboy.com/>



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-dev/attachments/20230125/8ca639e3/attachment.htm>