[PD] L2Ork Pd update now available

Jonathan Wilkes jancsika at yahoo.com
Thu Dec 16 23:28:15 CET 2010



--- On Thu, 12/16/10, Roman Haefeli <reduzent at gmail.com> wrote:

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

I've tagged many libraries so far with a [pd META] subpatch that 
has a KEYWORDS tag, and I've got a object-search feature where, 
for instance, you can search for objects that play a soundfile 
(keyword "soundfile"), manipulate or store lists ("list_op"), 
take user input ("user_input"), and so on.  You can also search 
for objects that manipulate lists and take user input, or objects 
that objects that take a symbol in the left inlet and output a 
list.

The problem with reorganizing libraries is it's a lot of work for a 
minor convenience-- the person who is looking for list-manipulating 
objects is happy if you have libdir "list_op", but then what about 
the person who wants to find that GUI object within the list_op 
library?  I suppose it's a bit easier to sift through a 100 
object library vs. 1500 objects, but it's still a waste of time.

-Jonathan

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


      



More information about the Pd-list mailing list