[PD] L2Ork Pd update now available

[Jonathan Wilkes]

--- On Thu, 12/16/10, Ivica Ico Bukvic <ico at vt.edu> wrote:

> From: Ivica Ico Bukvic <ico at vt.edu>
> Subject: Re: [PD] L2Ork Pd update now available
> To: "Roman Haefeli" <reduzent at gmail.com>
> Cc: pd-list at iem.at
> Date: Thursday, December 16, 2010, 4:00 PM
> 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.

It's also a matter of the developer writing a script to find all 
cases of the 
aliases in the current documentation and change the ones that have 
the deprecated name-- and if you're keeping the long name and 
discarding the short, to actually open each modified patch and make 
sure the new name doesn't collide with, say, a comment, or another 
object.  But most importantly, making sure any externals that are 
abstractions have the correct name in their guts (which, if not 
correct, will adversely affect the mood of a user who just went to 
the trouble of making/running a script to use this flavor of Pd).

-Jonathan

> 
> >   
> > 
> > > 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...
> 
> 
> _______________________________________________
> Pd-list at iem.at
> mailing list
> UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
>