[PD] L2Ork Pd update now available

[Ivica Ico Bukvic]

On Thu, 2010-12-16 at 14:04 +0100, Roman Haefeli wrote:
> 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.

Actually, they are not hard at all. I already tried building the whole
thing with aliases and it boils down to changing a few lines in the
installer. That said, I've reverted it back as I philosophically agree
with Hans. There is no reason for those aliases to exist other than
backward compatibility. Then again, it is exactly this kind of backward
compatibility (imho) that has been keeping Pd from evolving faster. At
some point one simply has to leave some things behind to be able to move
forward faster. And these aliases are such an easy fix that even in the
context of backwards-compatibility it is a matter of a simple script
updating your old patches and replacing object aliases with the original
ones.

>   
> 
> > 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.
> 

Good points. Time permitting, I may put this on my todo list...