Alexandre Torres Porres <porres@gmail.com> 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
_______________________________________________
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list