--- On Thu, 12/16/10, Roman Haefeli <reduz...@gmail.com> wrote:
> From: Roman Haefeli <reduz...@gmail.com> > Subject: Re: [PD] L2Ork Pd update now available > To: "Ivica Ico Bukvic" <i...@vt.edu> > Cc: pd-list@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@iem.at > mailing list > UNSUBSCRIBE and account-management -> > http://lists.puredata.info/listinfo/pd-list > _______________________________________________ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list