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

[IOhannes m zmoelnig]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 840 bytes
Desc: OpenPGP digital signature
URL: <http://lists.puredata.info/pipermail/pd-dev/attachments/20230123/b72fcfea/attachment.sig>