Synonym for pack/unpack: - Box/unbox Jakob
> On 23 Jan 2023, at 08.40, IOhannes m zmoelnig <[email protected]> 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 > [email protected] > https://lists.puredata.info/listinfo/pd-dev _______________________________________________ Pd-dev mailing list [email protected] https://lists.puredata.info/listinfo/pd-dev
