>> 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/ > listinfo/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
