[PD] L2Ork Pd update now available

Roman Haefeli reduzent at gmail.com
Thu Dec 16 14:04:30 CET 2010


On Wed, 2010-12-15 at 23:41 -0500, Ivica Ico Bukvic wrote:
> > AFAIK, a2l can be replaced by the vanilla [list].
> 
> Then I agree with your decision to drop aliases altogether.

To me this discussion sounds like: "Aliases are hard to implement when
using the libdir format (which was not intended by original author
anyway), so let's drop them". IMHO, that's a weak base for such a
decision.  

> Perhaps all libs should be looked over for redundant copies and only the
> most stable/polished iterations should be left in the final build.

I agree, but I guess it's not that simple. How can one decide which
classes are 'valuable' enough to keep and which aren't? There's much
personal taste involved. Personally, I tend to be as restrictive as
possible and I rather use [list prepend bla]-[list trim] instead of
[whateverlib/prepend bla], although the vanilla-only approach requires
two objects for what could be done with only one object when using an
external. And still, if the decision is to include an external, which
one of several flavours? It's not only about stability and cleanness, if
all flavours are stable, but work slightly different from each other. 

Also, it's problematic to include modified libraries while keeping their
original name. It would make the portability of patches much more
complex, more complex than it is now. A patch using zexy in Pd-extended
wouldn't necessarily work in Pd-l2ork. Stating that the patch is
dependent on the zexy library would not be sufficient info to ensure
that it works where zexy is installed.

I tend to think, that the best option would be a transition to a
reorganized library library, which uses names not based on authors but
on functionality. New patches could use the new, clean and stable
libraries, while old ones would still work with old (current) libraries.
Such a transition would allow to drop aliases, to drop superfluous
object classes, and to create libraries with meaningful names.

Although I'd be a strong supporter of this idea, I'm probably not the
one to start this project. However, I'd happily migrate my patches to
the new library library and I'd also participate in discussions.

> Is
> there a list of such objects and their similarities somewhere to start
> digging through all this.

I don't think think so. 

Roman





More information about the Pd-list mailing list