So, I got a tutorial on installing externals that says *standard paths** is where to put them - check it here https://sites.google.com/site/porres/Using%20Pd%20Externals.pdf on page 6 (got it from Pd's FAQ https://puredata.info/docs/faq/how-do-i-install-externals-and-help-files, btw). 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?
My concern is to understand *current* Pd's state in order to revise my tutorial regarding canonical practices for managing/installing externals. *Let's please keep this focus and not break the discussion, such as what would be desirable to happen for Pd in the future, we could have separate threads for that.*
Thanks
- *Standard paths* defined as 3 standard search paths for Pd: *A) *Application
Specific; *B)* User specific; *C)* Global (where "A" is the "extra" folder, "B" & "C" are defined for each OS). "A" is only seen by the Pd application it's in. "B" is seen by all Pds for a user in a machine. And "C" is seen by All Pds / all users in a machine.
I agree.
As an w32 user, putting things on any of those 3 places makes them appear on the Pd Browser. Then we do [declare] or startup flags if necessary.
On 7/27/2017 10:13 PM, Alexandre Torres Porres wrote:
So, I got a tutorial on installing externals that says standard paths* is....
-- Mensaje telepatico asistido por maquinas.
2017-07-27 23:50 GMT-03:00 Lucas Cordiviola lucarda27@hotmail.com:
putting things on any of those 3 places makes them appear on the Pd Browser. Then we do [declare] or startup flags if necessary.
Yeah, I didn't mention in the tutorial/manual that this also adds them to the browser.
Thanks for remembering it
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
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 derek.x.kwan@gmail.com wrote:
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
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 megrimm@gmail.com:
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 derek.x.kwan@gmail.com wrote:
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/li stinfo/pd-list
-- ____________________ m.e.grimm, m.f.a, ed.m. syracuse u., tc3 megrimm.net ____________________
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/ listinfo/pd-list
2017-07-27 22:13 GMT-03:00 Alexandre Torres Porres porres@gmail.com:
So, I got a tutorial on installing externals (..) check it here https://sites.google.com/site/porres/Using%20Pd%20Externals.pdf
Oh, the above link is now dead, threw it away after revising it. A new revised version is now, temporarily, here https://drive.google.com/file/d/0B3AoiT0xk8fnYWV5anJZeXZ2MDg/view
Made many fixes to the older text, and I'm now describing the current scenario (Pd 0.48 test5)
cheers
I just gave it a fast read, looks perfect. All that has to be explained is explained.
Are you going to update "https://puredata.info/docs/faq/how-do-i-install-externals-and-help-files"https://puredata.info/docs/faq/how-do-i-install-externals-and-help-files ?
Mensaje telepatico asistido por maquinas.
On 7/28/2017 6:35 PM, Alexandre Torres Porres wrote: 2017-07-27 22:13 GMT-03:00 Alexandre Torres Porres <porres@gmail.commailto:porres@gmail.com>:
So, I got a tutorial on installing externals (..) check it herehttps://sites.google.com/site/porres/Using%20Pd%20Externals.pdf
Oh, the above link is now dead, threw it away after revising it. A new revised version is now, temporarily, herehttps://drive.google.com/file/d/0B3AoiT0xk8fnYWV5anJZeXZ2MDg/view
Made many fixes to the older text, and I'm now describing the current scenario (Pd 0.48 test5)
cheers
Are you going to update "https://puredata.info/docs/faq/how-do-i-install-externals-and-help-files"
https://puredata.info/docs/faq/how-do-i-install-externals-and-help-files ?
I had edited that entry before to include the first version of this tutorial as "further reading" - I just edited it again to include this latest version if that's what you were asking. I feel like many entries and other things in the puredata.info needs updating and editing, I have it in my "To Do" list to check it out.
2017-07-29 6:29 GMT-03:00 Lucas Cordiviola lucarda27@hotmail.com:
I just gave it a fast read, looks perfect. All that has to be explained is explained.
Are you going to update "https://puredata.info/docs/faq/how-do-i-install- externals-and-help-files" https://puredata.info/docs/faq/how-do-i-install-externals-and-help-files ?
Mensaje telepatico asistido por maquinas.
On 7/28/2017 6:35 PM, Alexandre Torres Porres wrote:
2017-07-27 22:13 GMT-03:00 Alexandre Torres Porres porres@gmail.com:
So, I got a tutorial on installing externals (..) check it here https://sites.google.com/site/porres/Using%20Pd%20Externals.pdf
Oh, the above link is now dead, threw it away after revising it. A new revised version is now, temporarily, here https://drive.google.com/file/d/0B3AoiT0xk8fnYWV5anJZeXZ2MDg/view
Made many fixes to the older text, and I'm now describing the current scenario (Pd 0.48 test5)
cheers
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/ listinfo/pd-list
2017-07-29 6:29 GMT-03:00 Lucas Cordiviola lucarda27@hotmail.com:
I just gave it a fast read, looks perfect. All that has to be explained is explained.
Thanks, I'm planning to add a couple of more examples, and use other libraries than just cyclone to illustrate
Cool,
I did some cosmetics on pd.info and made the link open on a new tab.
Mensaje telepatico asistido por maquinas.
On 7/29/2017 12:06 PM, Alexandre Torres Porres wrote:
I just edited it again to include this latest version if that's what you were asking
This looks great! Really well detailed guide Alex. This documentation is much needed.
This documentation is actually "How do I install Externals and Help File" - wheras the website simply answers "Where do I install External and Help Files.
I wonder if we could integrate this document into that page?
Part 2 of Alex's document would look good there in place of what's already there. And the rest of it could maybe be linked / referenced in other ways.
On 2017-07-29 10:19, Lucas Cordiviola wrote:
Cool,
I did some cosmetics on pd.info and made the link open on a new tab.
Mensaje telepatico asistido por maquinas.
On 7/29/2017 12:06 PM, Alexandre Torres Porres wrote:
I just edited it again to include this latest version if that's what you were asking
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
2017-07-29 13:45 GMT-03:00 jmejia@anestheticaudio.com:
This looks great! Really well detailed guide Alex. This documentation is much needed.
This documentation is actually "How do I install Externals and Help File"
- wheras the website simply answers "Where do I install External and Help
Files.
I wonder if we could integrate this document into that page?
Thanks for the feedbacks.
It's already linked there in that FAQ entry, for "more details". Further work on that website soon is important, as I mentioned.
There's also been an internal talk about including this in the official Pd documentation. Dan mentioned something about it... we'll see...
I'm still revising it, I think it will still need a bit more work until I'm fully satisfied
cheers
I also updated:
https://puredata.info/Members/jb/ext-doc
that is linked from: tutorials/howtos / installing
Mensaje telepatico asistido por maquinas.
On 7/29/2017 1:58 PM, Alexandre Torres Porres wrote:
2017-07-29 13:45 GMT-03:00 <jmejia@anestheticaudio.commailto:jmejia@anestheticaudio.com>:
This looks great! Really well detailed guide Alex. This documentation is much needed.
This documentation is actually "How do I install Externals and Help File" - wheras the website simply answers "Where do I install External and Help Files.
I wonder if we could integrate this document into that page?
Thanks for the feedbacks.
It's already linked there in that FAQ entry, for "more details". Further work on that website soon is important, as I mentioned.
There's also been an internal talk about including this in the official Pd documentation. Dan mentioned something about it... we'll see...
I'm still revising it, I think it will still need a bit more work until I'm fully satisfied
cheers
Pd-list@lists.iem.atmailto:Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
-
Alexandre Torres Porres -
Derek Kwan -
jmejia＠anestheticaudio.com -
Lucas Cordiviola -
me.grimm