[PD] [PD-announce] Pd-extended 0.43.4 released!)

Ed Kelly morph_2016 at yahoo.co.uk
Fri Feb 1 14:55:51 CET 2013


OK, so Pd-extended doesn't load any libs by default (except Gem of course).
I'd like to suggest a fix for a problem I've encountered, especially when moving patches. 

Would there be a reverse way of finding out what libs are missing from a patch? Even just to generate a file, it would be a good idea to be able to search the libs and find out what you need to [import] to get a patch made on pre 0.43 Pd-extended to work.

Perhaps it could be an adaptation of the search plugin (nice work Jonathan ;-)

Ta,
Ed 

Gemnotes-0.2: Live music notation for Pure Data, now with dynamics!
http://sharktracks.co.uk/



>________________________________
> From: Hans-Christoph Steiner <hans at at.or.at>
>To: Jonathan Wilkes <jancsika at yahoo.com> 
>Cc: "pd-list at iem.at" <pd-list at iem.at> 
>Sent: Thursday, 31 January 2013, 17:42
>Subject: Re: [PD] standard library (was Re: [PD-announce] Pd-extended 0.43.4 released!)
> 
>On 01/31/2013 11:45 AM, Jonathan Wilkes wrote:
>> 
>> 
>> ----- Original Message -----
>>> From: Hans-Christoph Steiner <hans at at.or.at>
>>> To: pd-list at iem.at
>>> Cc: 
>>> Sent: Wednesday, January 30, 2013 4:40 PM
>>> Subject: Re: [PD] [PD-announce] Pd-extended 0.43.4 released!
>>>
>> 
>> [...]
>> 
>>> * new standard library that is larger and more consistent than what's in
>>> vanilla, things like all math and logic objects both message and signal
>>> included, rather than needed to load a library (i.e. zexy) for some of them.
>>> It would prioritize correctness and consistency over backwards compatibility.
>> 
>> That's a royal waste of your time.  I'm certain you wouldn't advocate _moving_
>> objects from various libs to one standard lib-- as that would break backwards
>> compatability-- so you must be advocating copying them.  Both would have the
>> direct affect of confusing users-- the former by _breaking_ all kinds of help docs,
>> tutorials, and lots else that's more or less part of the "standard" Pd world at
>> this point; and the latter by returning two results in a search for an object that
>> happens to be in the standard library.  Either is also a royal waste of the users' time.
>> 
>> If there are specific objects inside zexy or hans that need to be superceded by
>> an object with a better design in order to get more consistency, or if there are
>> objects that haven't been created yet that would add needed functionality, let's
>> talk about those cases.  But [import hans zexy lib_to_be_coded] is a perfectly
>> reasonable interface for loading 90% of what the user needs, so let's not go
>> breaking stuff for the sake of theoretical consistency.  For the other 10% it's
>> just fine for the user to search for that functionality and use the prefix
>> that is shown in the search results, or click the "info" icon to read about the
>> relevant library, or use [import], or do all three.
>
>Yes, it'll be a chunk of work, but I strongly believe it'll be worthwhile.
>Python3 is a good example of this kind of thing.  All the existing libraries
>would remain as they are, so backwards compatibility would be fully available.
>
>I agree theoretical consistency is not a worthy goal, that's not the point
>here at all. [import zexy] is a good example.  Let's say a user is looking for
>objects to make and manipulate symbols, how about calling tat library
>"symboltricks" or something descriptive, rather than an arbitrary name 'zexy'.
>In python, if I want to work with URLs, I load a 'urllib' or maybe 'urllib2'.
>
>The point is that the old way of organizing libraries was around the author,
>not what the library does, like zexy.  Newer libs like iemguts, pmpd, log,
>etc. are organized around a topic, and that makes much more sense.  That's a
>very widely established paradigm for libraries across basically all languages.
>
>Honestly, in the long run I think this will be less work than maintaining the
>system as it is now.  There are so many exceptions and quirks that is really
>is hard to make progress because some forgotten quirk comes back and bites you.
>
>>> * no libraries but the standard library loaded by default.
>>>
>>> * the possibility to load "distro profiles" for compatibilityYes, it'll be a chunk of work, but I strongly believe it'll be worthwhile.  Python3 is a good example of this kind of thing.  All the existing libraries would remain as they are, so backwards compatibility would be fully available. with 
>>> Pd-vanilla
>>> and Pd-extended
>>>
>>> * all of Pd-vanilla's objects as a separate 'vanilla' library.
>> 
>> In the search plugin I'm judging vanilla objects based on
>> whether the help patch is inside 5.reference, and returning
>> them first in the results.  I asked you awhile back if the
>> subdirs in "doc" are subject to change and you said they
>> were a standard part of Pd that wasn't likely to change.
>> If want the "vanilla" lib for the sake of consistency,
>> you won't get it because the vanilla help patches must
>> remain in 5.reference.  If you copy them to vanilla/ again
>> you would create UX problems as a search will return
>> two results for every vanilla object.
>> 
>> -Jonathan
>
>I think it'll be worthwhile to fix that quirk, and only have a single method
>that applies for all bjects and libraries, including 'vanilla'.  This points
>to exactly what I'm talking about: this is a random, unneeded exception that's
>there because of historical reasons, but is not useful in its own right.
>
>Most of the objects in this new standard library would likely change only
>slightly so the help can be taken from PDDP and tweaked.
>
>As for changing the tutorial sections in doc, I did not want to take on the
>maintenance of modified version, but I always thought it would be nice to have
>improved versions of them.  You've started that project, so I plan on using
>your work there.  You've already created massive improvements in the general
>help system, I expect no less with your effort on the included tutorials. :-D
>no pressure... ;)
>
>.hc
>
>_______________________________________________
>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