Good thoughts indeed Derek, which also points me to more details I could deal with in this documentation, thanks. So, we agree it's the "normal way" and I also agree things can still be improved, but we could discuss that in a different thread, like I said ;)
2017-07-28 12:18 GMT-03:00 me.grimm <[email protected]>: > >> the pros of using standard paths for externals are their > >>functionality with the Pd browser, and simplifying pathing, > > good thoughts... > > >>simplify the Pd experience > > especially this > > +1 > > On Fri, Jul 28, 2017 at 2:12 AM, Derek Kwan <[email protected]> > wrote: > >> Alexandre Torres Porres <[email protected]> writes: >> >> > My view is reinforced by [declare]'s object design, which loads >> > externals/libs from there with the -stdpath & -stdlib flags. Who >> > agrees/disagrees? and if standard paths* are not good for externals, >> > what they good for? >> >> Some random, scattered thoughts on the topic: >> >> I think there are many issues that arise with the use of standard paths >> although I would advocate for their use with library management and the >> use of standard paths seems to be prevalent across other creative coding >> platforms and programming language enviornments. >> >> In a sense, I suppose standard paths could be seen as less transparent >> since the object binaries and abstractions aren't in the immediate >> vicinity of the patches worked on. And with Pd-extended, a lot of people >> assumed that objects were just there as part of the typical Pd install >> and so people need to be helped out with what libraries are, where and >> how to install them, etc. I think this a lot of this stuff is solved >> with Deken by automating the whole process and also by people like >> myself and Alex who have writted thorough documentation of how the whole >> thing works. I'd agree that the concept is just yet another thing to >> teach/learn when getting accustomed to Pd and perhaps very casual users >> don't need to understand the concept of standard paths and how they >> work, but I don't the concept is so heady as to not be teachable in a >> relatively concise manner to new users and it's a concept that carries >> over to situations outside of Pd. >> >> Additionally, the use of standard paths brings up issues of libraries >> "locally" installed in specific project folders vs "globally" installed >> in a user's folder (and furthermore, "globally" installed in system >> folders outside of a user's folder). In this case, I'd propose perhaps >> some sort of hierarchy where local installs take precedence over user >> global installs which take precedence over system global >> installs. Perhaps this may be easier said than done due to how libraries >> are loaded at start-up and the scopes of different Pd windows being >> open, and what to do when they're closed or switched, what to do with >> the Pd browser,... but at least as an end user, this hierarchy seems to >> make the most sense to me. >> >> Standard paths interacting with the Pd browser can be kinda messy. For >> objects to show up in the browser, they need a help file (and here I'd >> propose perhaps allowing abstraction patches, ie patches that don't end >> in -help.pd, to appear as well since sometimes they are documented well >> enough not to need help patches). And even with navigating the Pd >> browser, the functionality of objects is unclear since there's no >> description field (but I think I'm getting off-track here >> haha). Double-loading libraries means they show up twice in the Pd >> browser (I suppose I don't really see a good way around this). >> >> Anyways, the pros of using standard paths for externals are their >> functionality with the Pd browser, and simplifying pathing, and well, >> having standard paths between different patcher windows, which simplify >> the Pd experience, especially when not using a saved patch in a specific >> project folder but rather a new patch. >> >> Derek >> >> _______________________________________________ >> [email protected] mailing list >> UNSUBSCRIBE and account-management -> https://lists.puredata.info/li >> stinfo/pd-list >> > > > > -- > ____________________ > m.e.grimm, m.f.a, ed.m. > syracuse u., tc3 > megrimm.net > ____________________ > > _______________________________________________ > [email protected] mailing list > UNSUBSCRIBE and account-management -> https://lists.puredata.info/ > listinfo/pd-list > >
_______________________________________________ [email protected] mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
