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

[Jakob Skouborg]

Synonym for pack/unpack:
- Box/unbox

Jakob

> On 23 Jan 2023, at 08.40, IOhannes m zmoelnig <zmoelnig at iem.at> wrote:
> 
> On 1/17/23 17:13, Miller Puckette via Pd-dev wrote:
>>> - [pack~] and [unpack~] are of course natural names for these objects.
>>> *unfortunately* i have added objects of the same name (but with different
>>> functionality) to zexy about 23 years ago. (the objects predate zexy's
>>> use of *any* VCS; but the copyright boilerplate says 2000/09/01 and i
>>> have no reason to distrust it).
>>> so i expect that either old patches that use zexy's [pack~]/[unpack~] are
>>> going to break, or the new multichannel [pack~]/[unpack~] won't be usable
>>> if zexy is loaded as a multi-object library.
>>> 
>> Hmm... well, old patches should run OK if the lib is explicitly loaded.
>> But it's a bother that new patches that pull zexy in explicitly won't
>> be able to use pack~ and unpack~. 
> 
> 
> if possible i would like to avoid that.
> 
>> The best solution I can think of is
>> to either find a different (unused) name for the new pack~/unpack~ or
> 
> i would prefer this.
> howe about the [split~]/[merge~] pair suggested by Jean-Yves?
> 
>> to offer a new name to zexy's versions (and keep the old ones too, perhaps
>> in a separate "library").
> 
> 
> i'm mostly concerned about embedding old abstractions (that use zexy's [unpack~]/[pack~]) that are to be embedded in new patches (that want to use multichannel capabilities), so the two should be able to co-exist.
> 
> in retrospect i wouldn't have named the zexy objects like i did, but i was young and needed the money.
> 
> gmdasr
> IOhannes
> _______________________________________________
> Pd-dev mailing list
> Pd-dev at lists.iem.at
> https://lists.puredata.info/listinfo/pd-dev