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 <h...@at.or.at> >To: Jonathan Wilkes <jancs...@yahoo.com> >Cc: "pd-list@iem.at" <pd-list@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 <h...@at.or.at> >>> To: pd-list@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@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