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