There seems to be a bit of FUD in this "discussion."
Some things from my perspective:
Pd's library/path mechanism is largely oriented toward *local* libs first and *global* ones later, ie. download externals to individual project (sub)folders. I believe the centralized loading was added later on in Pd-extended. If we follow the "programming language model", this might be similar to installing a Python egg locally or globally. I don't see how supporting both modes of working is a problem.
IOhannes convinced me, over time, that the "stdpath" loading mechanism used by the "extra" folder is problematic as it adds too many (sub) search paths by default and it becomes harder to tell/control what's being loaded. The "better way" is for people to specify those externals paths directly, either with the user search paths and/or declare. There is much less ambiguity as to what's going on at the loss of "just put things in this place" ease.
As suggested by Alexandre, I wrote a PR to help address how declare search when using -path & -lib by having them search along user search paths as well: https://github.com/pure-data/pure-data/pull/205 https://github.com/pure-data/pure-data/pull/205. I feel this is a much closer method of using declare to how other programming languages handle such things, ie. Lua's require.
The Pd Documents path (aka ~/Documents/Pd) is simply a helper location for beginners. It is only a regular user search path added by default (when desired) and does not search subfolders. Nobody has to use it and it can be disabled at any time.
Yes, the macOS hiding the ~/Library folder is problematic for many users as they don't know how to show it and are afraid to modify things within it. I've recently taught classes to beginners that are just learn gin the concept of a "file system" as they grew up mainly using "mobile phones" ... Plus, ~/Library/Pd was also a "kitchen sink" std path with the issues listed in #2.
I've attempted to provide some solutions to various issues outlined over the last year regarding [declare] and folders. It would be helpful to get more feedback earlier on in testing / experimentation, rather well after a release. OTOH if I attempted to do work for free on Pd that pleased *everyone*, I suppose I wouldn't bother.
(7. Code talks.)
Dan Wilcox @danomatika http://twitter.com/danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
2018-06-13 20:18 GMT-03:00 Dan Wilcox danomatika@gmail.com:
- IOhannes convinced me, over time, that the "stdpath" loading mechanism
used by the "extra" folder is problematic as it adds too many (sub) search paths by default and it becomes harder to tell/control what's being loaded.
hmm, I see...
The "better way" is for people to specify those externals paths directly, either with the user search paths and/or declare. There is much less ambiguity as to what's going on at the loss of "just put things in this place" ease.
But now we have a folder like ~/Documents/Pd that Pd suggests you to use, and then it creates it for you, and also creates ~/Documents/Pd/externals, and Deken puts thins in there for you... So, where I'm getting at is that this new process provides exactly that "*just put things in this place*" kind of ease, and therefore *no* loss - plus, we also have less ambiguity and avoid a problematic Ioading mechanism. In short, looks like a "win-win" situation...
cheers
Hello
I have a question about shader I search to work with gl_VertexID in .vert script. Some one have an example to implement this in .vert. With gl_VertexID, you can have an array of vertex with no input array for VBO and you can detreminate in real time the size of VertexArray with no latencies. I know that we can use this, but I have difficulties.
best regards
Philippe
I continue to search to use gl_VertexID
when I want to declare a version in vertex shader script, I want to declare for example #version 2.1 (it’s the openGL version when I check with print gemwin) but I have this in the PD_Terminal ERROR: 0:1: '' : version '2' is not supported
Can I use a version 2 for a vertex shader ?
if I don’t declare a version gl_VertexID is not recognized
Philippe
Le 14 juin 2018 à 06:27, Philippe Boisnard philemon1@mac.com a écrit :
Hello
I have a question about shader I search to work with gl_VertexID in .vert script. Some one have an example to implement this in .vert. With gl_VertexID, you can have an array of vertex with no input array for VBO and you can detreminate in real time the size of VertexArray with no latencies. I know that we can use this, but I have difficulties.
best regards
Philippe _______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Hi Philippe,
On 14/06/18 10:51, Philippe Boisnard wrote:
I continue to search to use gl_VertexID
when I want to declare a version in vertex shader script, I want to declare for example #version 2.1 (it’s the openGL version when I check with print gemwin) but I have this in the PD_Terminal ERROR: 0:1: '' : version '2' is not supported
The GL/GLSL version numbering is a bit obscure:
https://stackoverflow.com/questions/19021567/finding-supported-glsl-version#...
For OpenGL 2.1 you need this as first line of your shader:
#version 120
The good news is that gl_VertexID is supported in almost all GLSL versions:
http://docs.gl/sl4/gl_VertexID
For OpenGL ES (as found on embedded devices, eg mobile phones) you might not be so lucky:
http://docs.gl/el3/gl_VertexID
But I don't know if Gem supports attribute-less rendering (ie, just using gl_VertexID without any vertex data or element index buffers).
Claude
Can I use a version 2 for a vertex shader ?
if I don’t declare a version gl_VertexID is not recognized
Philippe
Le 14 juin 2018 à 06:27, Philippe Boisnard philemon1@mac.com a écrit :
Hello
I have a question about shader I search to work with gl_VertexID in .vert script. Some one have an example to implement this in .vert. With gl_VertexID, you can have an array of vertex with no input array for VBO and you can detreminate in real time the size of VertexArray with no latencies. I know that we can use this, but I have difficulties.
best regards
Philippe _______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
o use gl_VertexID with #version 120 it ’s necessar to indicate #extension : #extension GL_EXT_gpu_shader4 : require
Le 14 juin 2018 à 13:12, Claude Heiland-Allen claude@mathr.co.uk a écrit :
Hi Philippe,
On 14/06/18 10:51, Philippe Boisnard wrote:
I continue to search to use gl_VertexID
when I want to declare a version in vertex shader script, I want to declare for example #version 2.1 (it’s the openGL version when I check with print gemwin) but I have this in the PD_Terminal ERROR: 0:1: '' : version '2' is not supported
The GL/GLSL version numbering is a bit obscure:
https://stackoverflow.com/questions/19021567/finding-supported-glsl-version#... https://stackoverflow.com/questions/19021567/finding-supported-glsl-version#19022416
For OpenGL 2.1 you need this as first line of your shader:
#version 120
The good news is that gl_VertexID is supported in almost all GLSL versions:
http://docs.gl/sl4/gl_VertexID http://docs.gl/sl4/gl_VertexID
For OpenGL ES (as found on embedded devices, eg mobile phones) you might not be so lucky:
http://docs.gl/el3/gl_VertexID http://docs.gl/el3/gl_VertexID
But I don't know if Gem supports attribute-less rendering (ie, just using gl_VertexID without any vertex data or element index buffers).
Claude
Can I use a version 2 for a vertex shader ?
if I don’t declare a version gl_VertexID is not recognized
Philippe
Le 14 juin 2018 à 06:27, Philippe Boisnard philemon1@mac.com a écrit :
Hello
I have a question about shader I search to work with gl_VertexID in .vert script. Some one have an example to implement this in .vert. With gl_VertexID, you can have an array of vertex with no input array for VBO and you can detreminate in real time the size of VertexArray with no latencies. I know that we can use this, but I have difficulties.
best regards
Philippe _______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailto:Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list https://lists.puredata.info/listinfo/pd-list
-- https://mathr.co.uk https://mathr.co.uk/
Pd-list@lists.iem.at mailto:Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list https://lists.puredata.info/listinfo/pd-list
Philippe,
please don't reply to a random email from the list when you actually want to start a new topic (As I just did for illustrating my point). It breaks the threads in an email client or the mailman archive. It's ugly. It's against the Pd-list netiquette.
http://puredata.info/community/lists/Netiquette
On 14.06.2018 06:27, Philippe Boisnard wrote:
Hello
I have a question about shader I search to work with gl_VertexID in .vert script. Some one have an example to implement this in .vert. With gl_VertexID, you can have an array of vertex with no input array for VBO and you can detreminate in real time the size of VertexArray with no latencies. I know that we can use this, but I have difficulties.
best regards
Philippe _______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Hey Dan
Thanks for trying to explain.
On Thu, 2018-06-14 at 01:18 +0200, Dan Wilcox wrote:
There seems to be a bit of FUD in this "discussion."
Maybe things aren't that bad as they were presented. For my part, I lost track of who favors what kind of design.
Some things from my perspective:
- Pd's library/path mechanism is largely oriented toward *local*
libs first and *global* ones later, ie. download externals to individual project (sub)folders.
Pd already used to work like that for quite a while, no?
I believe the centralized loading was added later on in Pd-extended.
I don't understand what you mean by that. Pd-extended already pre- loaded a subset of the installed externals (do you mean this?), which - imho - was a bad design choice. It meant there was one person deciding what comes pre-loaded and what not.
If we follow the "programming language model", this might be similar to installing a Python egg locally or globally. I don't see how supporting both modes of working is a problem.
Me neither.
- IOhannes convinced me, over time, that the "stdpath" loading
mechanism used by the "extra" folder is problematic as it adds too many (sub) search paths by default and it becomes harder to tell/control what's being loaded.
Forgive my ignorance, but I don't understand. Does Pd now look into extra's subfolders? Currently I still have to actively load stuff with [declare -stdlib] or [declare -stdpath].
The "better way" is for people to specify those externals paths directly, either with the user search paths and/or declare. There is much less ambiguity as to what's going on at the loss of "just put things in this place" ease.
So paths added by the users will be searched by deken? So instead of specifying paths to the library root - as we currently do it - adding a path in the future means adding a searchpath that is container for many libraries? And deken will find libraries inside the newly added searchpath root?
- As suggested by Alexandre, I wrote a PR to help address how
declare search when using -path & -lib by having them search along user search paths as well: https://github.com/pure-data/pure- data/pull/205. I feel this is a much closer method of using declare to how other programming languages handle such things, ie. Lua's require.
OK, I hopefully understand now. Am I right in thinking that declare's
-stdlib, -stdpath flags are considered superfluous because -lib and
-path will scan all searchpaths in a local -> global order, including
the parent patch's folder?
- The Pd Documents path (aka ~/Documents/Pd) is simply a helper
location for beginners. It is only a regular user search path added by default (when desired) and does not search subfolders.
Now you challenge my understanding of the term searchpath again. I thought the new idea is that you will be able to load libraries with [declare] from user-added searchpaths? What's the point of creating that folder then?
Nobody has to use it and it can be disabled at any time.
My beef with it is that - the way it is presented to me - it suggests to do things that create confusion later.
As a new user:
"Do you want to create ~/Documents/Pd"
Yes
"Do you want to add it to the searchpaths?"
Yes
When downloading stuff with deken: "Do you want to install 'mylib' to ~/Documents/Pd?"
Yes
Now, I'm going to load mylib with [declare -{std}path mylib] in my patch which fails.
What am I missing here?
- Yes, the macOS hiding the ~/Library folder is problematic for many
users as they don't know how to show it and are afraid to modify things within it. I've recently taught classes to beginners that are just learn gin the concept of a "file system" as they grew up mainly using "mobile phones"
I don't see how deken requires users to have a notion about a filesystem. Ideally, I'd use deken to tell _what_ I want to install. Ideally, I'd tell my patch through [declare] _what_ to load. All the _where_ stuff shouldn't be a question neither at installing nor loading time. The _where_ stuff should only matter when the user tweaks their environment: "I'd rather put my 4.5 TB of Pd externals on my external drive ".
... Plus, ~/Library/Pd was also a "kitchen sink" std path with the issues listed in #2.
- I've attempted to provide some solutions to various issues
outlined over the last year regarding [declare] and folders. It would be helpful to get more feedback earlier on in testing / experimentation, rather well after a release.
Valid and important point. I will try to the get a more clear picture from the actual implementation instead of a messy Pd list thread.
Roman
- The Pd Documents path (aka ~/Documents/Pd) is simply a helper
location for beginners. It is only a regular user search path added by default (when desired) and does not search subfolders.
Now you challenge my understanding of the term searchpath again. I thought the new idea is that you will be able to load libraries with [declare] from user-added searchpaths? What's the point of creating that folder then?
because Pd didn't create any folder by default for installing libraries (unlike most other programs). rather than creating the folder in one of those awkward user paths (btw, in Windows it's something like C:\Users\Christof\AppData\Roaming\Pd - of course it's hidden), we offer the user a folder they can easily access, following the Arduino model.
Yes
Now, I'm going to load mylib with [declare -{std}path mylib] in my patch which fails.
What am I missing here?
because right now [declare] doesn't work with user specified paths (yet). Dan's PR attempts to fix this.
Gesendet: Donnerstag, 14. Juni 2018 um 09:52 Uhr Von: "Roman Haefeli" reduzent@gmail.com An: Pd-List pd-list@lists.iem.at Betreff: Re: [PD] standard paths for externals
Hey Dan
Thanks for trying to explain.
On Thu, 2018-06-14 at 01:18 +0200, Dan Wilcox wrote:
There seems to be a bit of FUD in this "discussion."
Maybe things aren't that bad as they were presented. For my part, I lost track of who favors what kind of design.
Some things from my perspective:
- Pd's library/path mechanism is largely oriented toward *local*
libs first and *global* ones later, ie. download externals to individual project (sub)folders.
Pd already used to work like that for quite a while, no?
I believe the centralized loading was added later on in Pd-extended.
I don't understand what you mean by that. Pd-extended already pre- loaded a subset of the installed externals (do you mean this?), which - imho - was a bad design choice. It meant there was one person deciding what comes pre-loaded and what not.
If we follow the "programming language model", this might be similar to installing a Python egg locally or globally. I don't see how supporting both modes of working is a problem.
Me neither.
- IOhannes convinced me, over time, that the "stdpath" loading
mechanism used by the "extra" folder is problematic as it adds too many (sub) search paths by default and it becomes harder to tell/control what's being loaded.
Forgive my ignorance, but I don't understand. Does Pd now look into extra's subfolders? Currently I still have to actively load stuff with [declare -stdlib] or [declare -stdpath].
The "better way" is for people to specify those externals paths directly, either with the user search paths and/or declare. There is much less ambiguity as to what's going on at the loss of "just put things in this place" ease.
So paths added by the users will be searched by deken? So instead of specifying paths to the library root - as we currently do it - adding a path in the future means adding a searchpath that is container for many libraries? And deken will find libraries inside the newly added searchpath root?
- As suggested by Alexandre, I wrote a PR to help address how
declare search when using -path & -lib by having them search along user search paths as well: https://github.com/pure-data/pure- data/pull/205. I feel this is a much closer method of using declare to how other programming languages handle such things, ie. Lua's require.
OK, I hopefully understand now. Am I right in thinking that declare's -stdlib, -stdpath flags are considered superfluous because -lib and
-path will scan all searchpaths in a local -> global order, including the parent patch's folder?
- The Pd Documents path (aka ~/Documents/Pd) is simply a helper
location for beginners. It is only a regular user search path added by default (when desired) and does not search subfolders.
Now you challenge my understanding of the term searchpath again. I thought the new idea is that you will be able to load libraries with [declare] from user-added searchpaths? What's the point of creating that folder then?
Nobody has to use it and it can be disabled at any time.
My beef with it is that - the way it is presented to me - it suggests to do things that create confusion later.
As a new user:
"Do you want to create ~/Documents/Pd"
Yes
"Do you want to add it to the searchpaths?"
Yes
When downloading stuff with deken: "Do you want to install 'mylib' to ~/Documents/Pd?"
Yes
Now, I'm going to load mylib with [declare -{std}path mylib] in my patch which fails.
What am I missing here?
- Yes, the macOS hiding the ~/Library folder is problematic for many
users as they don't know how to show it and are afraid to modify things within it. I've recently taught classes to beginners that are just learn gin the concept of a "file system" as they grew up mainly using "mobile phones"
I don't see how deken requires users to have a notion about a filesystem. Ideally, I'd use deken to tell _what_ I want to install. Ideally, I'd tell my patch through [declare] _what_ to load. All the _where_ stuff shouldn't be a question neither at installing nor loading time. The _where_ stuff should only matter when the user tweaks their environment: "I'd rather put my 4.5 TB of Pd externals on my external drive ".
... Plus, ~/Library/Pd was also a "kitchen sink" std path with the issues listed in #2.
- I've attempted to provide some solutions to various issues
outlined over the last year regarding [declare] and folders. It would be helpful to get more feedback earlier on in testing / experimentation, rather well after a release.
Valid and important point. I will try to the get a more clear picture from the actual implementation instead of a messy Pd list thread.
Roman_______________________________________________ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
2018-06-14 4:52 GMT-03:00 Roman Haefeli reduzent@gmail.com:
Does Pd now look into extra's subfolders?
If I got it right, the deal is that Pd always searches in "extra" (but not subfolders), so if you have a bunch of things in "extra", the thing is they're always in the search way, so it can be a good idea to keep it as clear as possible.
My beef with it is that - the way it is presented to me - it suggests to
do things that create confusion later. As a new user: "Do you want to create ~/Documents/Pd"?
Yes
"Do you want to add it to the searchpaths?"
Yes
It's just one question, the first one, but it does add it to the search path as well.
When downloading stuff with deken: "Do you want to install 'mylib' to ~/Documents/Pd?"
Yes
Now, I'm going to load mylib with [declare -{std}path mylib] in my patch which fails. What am I missing here?
Yes, there's the declare issue we know and are addressing, but I'd also like to highlight that Deken also asks if you want to add what you downloaded to the search path. This intentionally provided a working solution to this issue at the time of the release, making it all just work by clicking "yes" to stuff, which is quite fine for newcomers.
cheers
On Thu, 2018-06-14 at 14:18 -0300, Alexandre Torres Porres wrote:
Now, I'm going to load mylib with [declare -{std}path mylib] in my patch which fails. What am I missing here?
Yes, there's the declare issue we know and are addressing, but I'd also like to highlight that Deken also asks if you want to add what you downloaded to the search path. This intentionally provided a working solution to this issue at the time of the release, making it all just work by clicking "yes" to stuff, which is quite fine for newcomers.
OK. Just to be sure we are on the same page, I understand that the following assumptions will be true, once the PRs are accepted:
The user defines the environment. The user can define in the pre- ferences in which paths [declare] looks for libraries.
Patches can use [declare] to load libraries, regardless where they are installed as long as the install path was added as searchpath in the preferences
Patches don't need to know anything about the environment.
Example:
User adds '/home/jane/fanypdcollection/' to the paths in Pd's preferences. Then she installs iemnet to /home/jane/fancypdcollection/iemnet after she configured Deken to install libraries to /home/jane/fanypdcollection/. Then she creates a new patch, therein a [declare -path iemnet] and a [tcpclient] and the latter creates successfully.
Is this the idea?
Roman
2018-06-14 15:35 GMT-03:00 Roman Haefeli reduzent@gmail.com:
Is this the idea?
Yes! And it's working like that in my tests.
On Thu, 2018-06-14 at 16:32 -0300, Alexandre Torres Porres wrote:
2018-06-14 15:35 GMT-03:00 Roman Haefeli reduzent@gmail.com:
Is this the idea?
Yes! And it's working like that in my tests.
Ok, it's working for me, too. I see significant progress in that (after having cleared all preferences) I end up with a "working" setup by clicking myself through the defaults. Things get downloaded to ~/Documents/Pd/externals, which was automatically created added to the search paths. After installing externals through 'Find externals', I can load them by [declare -lib <mylib>] and [declare -path <mylib>].
So, does that mean the [declare]-flags -stdlib and -stdpath are obsolete now?
I can't spot any problems with the branch feature/declare-path, but virtually all of my patches are broken with it because of incompatible [declare] flags. I like the 'new way' much better, but I wonder what is a good path to get there. It's actually an easy thing to replace all occurences of -stdlib/-stdpath with -lib/path. But switching behaviour from one version of Pd to the next seems bold.
Roman
This is not a switch in behaviour as I see it, since you can keep things as they are and the behaviour is still the same. Hence, no compatibility breakage here.
Now, if you wanna do things differently, in a new way, as another option, then this is provided and you should adapt your patches.
So it is a matter of deciding wether if it is worth to change your setup or not...
cheers
2018-07-13 11:12 GMT-03:00 Roman Haefeli reduzent@gmail.com:
On Thu, 2018-06-14 at 16:32 -0300, Alexandre Torres Porres wrote:
2018-06-14 15:35 GMT-03:00 Roman Haefeli reduzent@gmail.com:
Is this the idea?
Yes! And it's working like that in my tests.
Ok, it's working for me, too. I see significant progress in that (after having cleared all preferences) I end up with a "working" setup by clicking myself through the defaults. Things get downloaded to ~/Documents/Pd/externals, which was automatically created added to the search paths. After installing externals through 'Find externals', I can load them by [declare -lib <mylib>] and [declare -path <mylib>].
So, does that mean the [declare]-flags -stdlib and -stdpath are obsolete now?
I can't spot any problems with the branch feature/declare-path, but virtually all of my patches are broken with it because of incompatible [declare] flags. I like the 'new way' much better, but I wonder what is a good path to get there. It's actually an easy thing to replace all occurences of -stdlib/-stdpath with -lib/path. But switching behaviour from one version of Pd to the next seems bold.
Roman
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/ listinfo/pd-list
2018-07-13 11:12 GMT-03:00 Roman Haefeli reduzent@gmail.com:
So, does that mean the [declare]-flags -stdlib and -stdpath are obsolete now?
yes, and this was mentioned in this thread already - but it is kept there for backwards compatibility concerns, for not to have a change in behaviour from one version to another, so your old configuration still works
On Fri, 2018-07-13 at 14:27 -0300, Alexandre Torres Porres wrote:
2018-07-13 11:12 GMT-03:00 Roman Haefeli reduzent@gmail.com:
So, does that mean the [declare]-flags -stdlib and -stdpath are obsolete now?
Oops, bad wording on my part. I should have said 'in the declare-path branch' instead of 'now' as readers might think it was already changed in Pd, which is _not_ the case. I'm talking about a feature branch that possibly/hopefully makes it into Pd.
yes, and this was mentioned in this thread already - but it is kept there for backwards compatibility concerns, for not to have a change in behaviour from one version to another, so your old configuration still works
Alright, that's absolutely correct. Old flags still work with old layout, new flags work with new layout. So there is no problem with the transition. Thanks for the clarification.
Roman
-
Alexandre Torres Porres -
Antoine Rousseau -
Christof Ressi -
Claude Heiland-Allen -
Dan Wilcox -
Max -
Philippe Boisnard -
Roman Haefeli