--- On Thu, 12/16/10, Roman Haefeli reduzent@gmail.com wrote:
From: Roman Haefeli reduzent@gmail.com Subject: Re: [PD] L2Ork Pd update now available To: "Ivica Ico Bukvic" ico@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