I just had another thought as for a way to provide more native-language help in Pd-extended. In the Help menu is the "Start Here!" item which takes you to http://puredata.info/docs/StartHere. I've made it possible to set that URL in the translation, so there can be http://puredata.info/docs/PourCommencer and http://puredata.info/docs/%E3%81%93%E3%81%93%E3%81%8B%E3%82%89%E5%A7%8B%E3%8... etc. That page is a short wiki page to tell people where they can get more help for learning Pd in their native language.
Also, that link could point to any webpage, it doesn't need to be puredata.info. But it should be a community oriented site where people can edit the page to improve it, IMHO.
To change the URL in your language, edit the translation: https://www.transifex.com/projects/p/puredata/resource/pd-extended/
.hc
https://puredata.info/docs/PourCommencer (Sorry for the Windows borders)
With the patch that goes along attached here.
pob
On 01/01/2013 20:35, Hans-Christoph Steiner wrote:
I just had another thought as for a way to provide more native-language help in Pd-extended. In the Help menu is the "Start Here!" item which takes you to http://puredata.info/docs/StartHere. I've made it possible to set that URL in the translation, so there can be http://puredata.info/docs/PourCommencer and http://puredata.info/docs/%E3%81%93%E3%81%93%E3%81%8B%E3%82%89%E5%A7%8B%E3%8... etc. That page is a short wiki page to tell people where they can get more help for learning Pd in their native language.
Also, that link could point to any webpage, it doesn't need to be puredata.info. But it should be a community oriented site where people can edit the page to improve it, IMHO.
To change the URL in your language, edit the translation: https://www.transifex.com/projects/p/puredata/resource/pd-extended/
.hc
----- Original Message -----
From: Hans-Christoph Steiner hans@at.or.at To: Pd List pd-list@iem.at Cc: Sent: Tuesday, January 1, 2013 2:35 PM Subject: [PD] translate the Start Here! page
I just had another thought as for a way to provide more native-language help in Pd-extended. In the Help menu is the "Start Here!" item which takes you to http://puredata.info/docs/StartHere.%C2%A0 I've made it possible to set that URL in the translation, so there can be http://puredata.info/docs/PourCommencer and http://puredata.info/docs/%E3%81%93%E3%81%93%E3%81%8B%E3%82%89%E5%A7%8B%E3%8... etc. That page is a short wiki page to tell people where they can get more help for learning Pd in their native language.
Also, that link could point to any webpage, it doesn't need to be puredata.info. But it should be a community oriented site where people can edit the page to improve it, IMHO.
To change the URL in your language, edit the translation: https://www.transifex.com/projects/p/puredata/resource/pd-extended/
.hc
You should update that page before encouraging translation. Otherwise the translators will include links to unmaintained projects like the Pd FLOSS Manual as has already happened.
-Jonathan
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On Jan 1, 2013, at 4:02 PM, Jonathan Wilkes wrote:
----- Original Message -----
From: Hans-Christoph Steiner hans@at.or.at To: Pd List pd-list@iem.at Cc: Sent: Tuesday, January 1, 2013 2:35 PM Subject: [PD] translate the Start Here! page
I just had another thought as for a way to provide more native-language help in Pd-extended. In the Help menu is the "Start Here!" item which takes you to http://puredata.info/docs/StartHere. I've made it possible to set that URL in the translation, so there can be http://puredata.info/docs/PourCommencer and http://puredata.info/docs/%E3%81%93%E3%81%93%E3%81%8B%E3%82%89%E5%A7%8B%E3%8... etc. That page is a short wiki page to tell people where they can get more help for learning Pd in their native language.
Also, that link could point to any webpage, it doesn't need to be puredata.info. But it should be a community oriented site where people can edit the page to improve it, IMHO.
To change the URL in your language, edit the translation: https://www.transifex.com/projects/p/puredata/resource/pd-extended/
.hc
You should update that page before encouraging translation. Otherwise the translators will include links to unmaintained projects like the Pd FLOSS Manual as has already happened.
Which link do you think should be removed? There isn't an official maintainer to the FLOSS Manuals english book, but its still quite good.
.hc
----- Original Message -----
From: Hans-Christoph Steiner hans@at.or.at To: Jonathan Wilkes jancsika@yahoo.com Cc: Pd List pd-list@iem.at Sent: Wednesday, January 2, 2013 10:05 AM Subject: Re: [PD] translate the Start Here! page
On Jan 1, 2013, at 4:02 PM, Jonathan Wilkes wrote:
----- Original Message -----
From: Hans-Christoph Steiner hans@at.or.at To: Pd List pd-list@iem.at Cc: Sent: Tuesday, January 1, 2013 2:35 PM Subject: [PD] translate the Start Here! page
I just had another thought as for a way to provide more native-language
help
in Pd-extended. In the Help menu is the "Start Here!" item
which
takes you to http://puredata.info/docs/StartHere.%C2%A0 I've made it possible to set
that URL
in the translation, so there can be
http://puredata.info/docs/PourCommencer and
http://puredata.info/docs/%E3%81%93%E3%81%93%E3%81%8B%E3%82%89%E5%A7%8B%E3%8... etc. That page is a short wiki page to tell people where they can get more help for learning Pd in
their
native language.
Also, that link could point to any webpage, it doesn't need to be puredata.info. But it should be a community oriented site where people
can
edit the page to improve it, IMHO.
To change the URL in your language, edit the translation: https://www.transifex.com/projects/p/puredata/resource/pd-extended/
.hc
You should update that page before encouraging translation. Otherwise the translators will include links to unmaintained projects like the Pd
FLOSS
Manual as has already happened.
Which link do you think should be removed? There isn't an official maintainer to the FLOSS Manuals english book, but its still quite good.
The FLOSS Pure Data Manual has a big, static, unmaintainable list of objects by category that gets more out of date every time pd-extended drops or adds a library.
Example of how this problem manifests itself: http://thread.gmane.org/gmane.comp.multimedia.puredata.general/82173/focus=8...
Notice that this user presumably followed a very reasonable path to finding objects: puredata.info -> FLOSS Manual -> FLOSS Manual Object List -> broken objects in his/her instance of Pd.
Also notice that a large portion of the FLOSS Manual object list doesn't even specify what library the externals belong to.
Also notice that the specific objects which the user asked about weren't even updated in the manual after the thread had ended, nor to date.
Also notice that neither you nor I are the least bit interested in fixing these problems in the FLOSS manual, and we're especially not interested in taking it on as a long term project. Who does that leave? If it leaves anyone wouldn't their time be better spent fixing the doc problems listed on the tracker than etching in stone a description of a moving target?
-Jonathan
.hc
On 01/02/2013 06:27 PM, Jonathan Wilkes wrote:
----- Original Message -----
From: Hans-Christoph Steiner hans@at.or.at To: Jonathan Wilkes jancsika@yahoo.com Cc: Pd List pd-list@iem.at Sent: Wednesday, January 2, 2013 10:05 AM Subject: Re: [PD] translate the Start Here! page
On Jan 1, 2013, at 4:02 PM, Jonathan Wilkes wrote:
----- Original Message -----
From: Hans-Christoph Steiner hans@at.or.at To: Pd List pd-list@iem.at Cc: Sent: Tuesday, January 1, 2013 2:35 PM Subject: [PD] translate the Start Here! page
I just had another thought as for a way to provide more native-language
help
in Pd-extended. In the Help menu is the "Start Here!" item
which
takes you to http://puredata.info/docs/StartHere. I've made it possible to set
that URL
in the translation, so there can be
http://puredata.info/docs/PourCommencer and
http://puredata.info/docs/%E3%81%93%E3%81%93%E3%81%8B%E3%82%89%E5%A7%8B%E3%8... etc. That page is a short wiki page to tell people where they can get more help for learning Pd in
their
native language.
Also, that link could point to any webpage, it doesn't need to be puredata.info. But it should be a community oriented site where people
can
edit the page to improve it, IMHO.
To change the URL in your language, edit the translation: https://www.transifex.com/projects/p/puredata/resource/pd-extended/
.hc
You should update that page before encouraging translation. Otherwise the translators will include links to unmaintained projects like the Pd
FLOSS
Manual as has already happened.
Which link do you think should be removed? There isn't an official maintainer to the FLOSS Manuals english book, but its still quite good.
The FLOSS Pure Data Manual has a big, static, unmaintainable list of objects by category that gets more out of date every time pd-extended drops or adds a library.
Example of how this problem manifests itself: http://thread.gmane.org/gmane.comp.multimedia.puredata.general/82173/focus=8...
Notice that this user presumably followed a very reasonable path to finding objects: puredata.info -> FLOSS Manual -> FLOSS Manual Object List -> broken objects in his/her instance of Pd.
Also notice that a large portion of the FLOSS Manual object list doesn't even specify what library the externals belong to.
Also notice that the specific objects which the user asked about weren't even updated in the manual after the thread had ended, nor to date.
Also notice that neither you nor I are the least bit interested in fixing these problems in the FLOSS manual, and we're especially not interested in taking it on as a long term project. Who does that leave? If it leaves anyone wouldn't their time be better spent fixing the doc problems listed on the tracker than etching in stone a description of a moving target?
That listing is indeed problematic, but I think most of the problems could be addressed by better describing what that listing is. For example, the user in that thread was not aware of how to load libraries, i.e. [import] or [declare -lib]. That's something that should be described in that book anyhow.
I'm very much interested in maintaining the FLOSS manuals book, and I've contributed to it in the past. These days, my time for Pd is quite limited. But I will try to find time to update key bits like that.
.hc
----- Original Message -----
From: Hans-Christoph Steiner hans@at.or.at To: Jonathan Wilkes jancsika@yahoo.com Cc: Pd List pd-list@iem.at Sent: Thursday, January 3, 2013 4:52 PM Subject: Re: [PD] translate the Start Here! page
On 01/02/2013 06:27 PM, Jonathan Wilkes wrote:
----- Original Message -----
From: Hans-Christoph Steiner hans@at.or.at To: Jonathan Wilkes jancsika@yahoo.com Cc: Pd List pd-list@iem.at Sent: Wednesday, January 2, 2013 10:05 AM Subject: Re: [PD] translate the Start Here! page
On Jan 1, 2013, at 4:02 PM, Jonathan Wilkes wrote:
----- Original Message -----
From: Hans-Christoph Steiner hans@at.or.at To: Pd List pd-list@iem.at Cc: Sent: Tuesday, January 1, 2013 2:35 PM Subject: [PD] translate the Start Here! page
I just had another thought as for a way to provide more
native-language
help
in Pd-extended. In the Help menu is the "Start
Here!" item
which
takes you to http://puredata.info/docs/StartHere.%C2%A0 I've made it
possible to set
that URL
in the translation, so there can be
http://puredata.info/docs/PourCommencer and
http://puredata.info/docs/%E3%81%93%E3%81%93%E3%81%8B%E3%82%89%E5%A7%8B%E3%8... etc. That page is a short
wiki
page to tell people where they can get more help for learning
Pd in
their
native language.
Also, that link could point to any webpage, it doesn't
need to be
puredata.info. But it should be a community oriented site
where people
can
edit the page to improve it, IMHO.
To change the URL in your language, edit the translation:
https://www.transifex.com/projects/p/puredata/resource/pd-extended/
.hc
You should update that page before encouraging translation.
Otherwise
the translators will include links to unmaintained projects like
the Pd
FLOSS
Manual as has already happened.
Which link do you think should be removed? There isn't an official
maintainer to the FLOSS Manuals english book, but its still quite good.
The FLOSS Pure Data Manual has a big, static, unmaintainable list of objects by category that gets more out of date every time pd-extended drops or adds a library.
Example of how this problem manifests itself:
http://thread.gmane.org/gmane.comp.multimedia.puredata.general/82173/focus=8...
Notice that this user presumably followed a very reasonable path to finding objects: puredata.info -> FLOSS Manual -> FLOSS Manual Object List
-> broken objects
in his/her instance of Pd.
Also notice that a large portion of the FLOSS Manual object list
doesn't even
specify what library the externals belong to.
Also notice that the specific objects which the user asked about
weren't even
updated in the manual after the thread had ended, nor to date.
Also notice that neither you nor I are the least bit interested in fixing
these
problems in the FLOSS manual, and we're especially not interested in
taking
it on as a long term project. Who does that leave? If it leaves anyone wouldn't their time be better spent fixing the doc problems listed on
the tracker
than etching in stone a description of a moving target?
That listing is indeed problematic, but I think most of the problems could be addressed by better describing what that listing is. For example, the user in that thread was not aware of how to load libraries, i.e. [import] or [declare -lib].
That's irrelevant in the case of object classes for which the library isn't even listed.
That's something that should be described in that book anyhow.
I'm very much interested in maintaining the FLOSS manuals book, and I've contributed to it in the past. These days, my time for Pd is quite limited. But I will try to find time to update key bits like that.
If you do find the time just use it to delete the entire static table of objects and replace it with the sentence "Click the Help menu and choose Search". Seriously, why would anyone spend time maintaining that when a) Pd vanilla users already have a static list with descriptions and b) Pd-extended now allows you to search by category?
-Jonathan
.hc
On 01/03/2013 06:08 PM, Jonathan Wilkes wrote:
----- Original Message -----
From: Hans-Christoph Steiner hans@at.or.at To: Jonathan Wilkes jancsika@yahoo.com Cc: Pd List pd-list@iem.at Sent: Thursday, January 3, 2013 4:52 PM Subject: Re: [PD] translate the Start Here! page
On 01/02/2013 06:27 PM, Jonathan Wilkes wrote:
----- Original Message -----
From: Hans-Christoph Steiner hans@at.or.at To: Jonathan Wilkes jancsika@yahoo.com Cc: Pd List pd-list@iem.at Sent: Wednesday, January 2, 2013 10:05 AM Subject: Re: [PD] translate the Start Here! page
On Jan 1, 2013, at 4:02 PM, Jonathan Wilkes wrote:
----- Original Message -----
From: Hans-Christoph Steiner hans@at.or.at To: Pd List pd-list@iem.at Cc: Sent: Tuesday, January 1, 2013 2:35 PM Subject: [PD] translate the Start Here! page
I just had another thought as for a way to provide more
native-language
help
in Pd-extended. In the Help menu is the "Start
Here!" item
which
takes you to http://puredata.info/docs/StartHere. I've made it
possible to set
that URL
in the translation, so there can be
http://puredata.info/docs/PourCommencer and
http://puredata.info/docs/%E3%81%93%E3%81%93%E3%81%8B%E3%82%89%E5%A7%8B%E3%8... etc. That page is a short
wiki
page to tell people where they can get more help for learning
Pd in
their
native language.
Also, that link could point to any webpage, it doesn't
need to be
puredata.info. But it should be a community oriented site
where people
can
edit the page to improve it, IMHO.
To change the URL in your language, edit the translation:
https://www.transifex.com/projects/p/puredata/resource/pd-extended/
.hc
You should update that page before encouraging translation.
Otherwise
the translators will include links to unmaintained projects like
the Pd
FLOSS
Manual as has already happened.
Which link do you think should be removed? There isn't an official
maintainer to the FLOSS Manuals english book, but its still quite good.
The FLOSS Pure Data Manual has a big, static, unmaintainable list of objects by category that gets more out of date every time pd-extended drops or adds a library.
Example of how this problem manifests itself:
http://thread.gmane.org/gmane.comp.multimedia.puredata.general/82173/focus=8...
Notice that this user presumably followed a very reasonable path to finding objects: puredata.info -> FLOSS Manual -> FLOSS Manual Object List
-> broken objects
in his/her instance of Pd.
Also notice that a large portion of the FLOSS Manual object list
doesn't even
specify what library the externals belong to.
Also notice that the specific objects which the user asked about
weren't even
updated in the manual after the thread had ended, nor to date.
Also notice that neither you nor I are the least bit interested in fixing
these
problems in the FLOSS manual, and we're especially not interested in
taking
it on as a long term project. Who does that leave? If it leaves anyone wouldn't their time be better spent fixing the doc problems listed on
the tracker
than etching in stone a description of a moving target?
That listing is indeed problematic, but I think most of the problems could be addressed by better describing what that listing is. For example, the user in that thread was not aware of how to load libraries, i.e. [import] or [declare -lib].
That's irrelevant in the case of object classes for which the library isn't even listed.
That's something that should be described in that book anyhow.
I'm very much interested in maintaining the FLOSS manuals book, and I've contributed to it in the past. These days, my time for Pd is quite limited. But I will try to find time to update key bits like that.
If you do find the time just use it to delete the entire static table of objects and replace it with the sentence "Click the Help menu and choose Search". Seriously, why would anyone spend time maintaining that when a) Pd vanilla users already have a static list with descriptions and b) Pd-extended now allows you to search by category?
Yes, searching makes much more sense most of the time. And there is even the option for browsing in Pd-extended as well. I'm ok with removing that section, but I think we should try to get more input from people before removing it.
One thing that should be easy to do is to 'unpublish' that section, so that it would only be visible in the edit mode. Then we can see who complains.
.hc
Am 03.01.2013 um 22:52 schrieb Hans-Christoph Steiner hans@at.or.at:
I'm very much interested in maintaining the FLOSS manuals book, and I've contributed to it in the past. These days, my time for Pd is quite limited. But I will try to find time to update key bits like that.
Derek has made me an admin of it, but I didn't have the time to look through it and do much with it. maybe we can do another sprint some time where we push it a bit.
max
Also notice that neither you nor I are the least bit interested in fixing these
problems in the FLOSS manual, and we're especially not interested in taking it on as a long term project. Who does that leave? If it leaves anyone wouldn't their time be better spent fixing the doc problems listed on the tracker than etching in stone a description of a moving target?
Well, if you have to teach Pd to art students who are used to using Photoshop and Final Cut Pro (as I do) the FLOSS manual page is very useful to give them some idea of what the objects are. It may not be 100% accurate, but at least it is (only) a start. I do hope that the search mechanism replaces static docs conceptually, but here is why they should be kept.
Learning Pd from scratch is not easy unless you are already a computer scientist. "How do I know what the objects are called" is I agree, the wrong question in so many ways. However, 80% of my undergraduate students basically give up at that point if they can't find the answer, and probably 60% of my masters students, often after saying "I hate Pd". This question usually comes up in the first lesson. I could criticise them for this, except that there is an impression that Pd is "open" as well as open-source. Is it? Or is it highly elitist? I think it can be both, but I don't want to kick away the ladder...
Perhaps the problem lies more with "standards" for documentation across the whole community - it's never going to happen (remember Pdpedia?) because the Pd community can be somewhat anarchic. Hats off to Hans - making Pd-extended work is like nailing jelly to the wall I guess.
There are some small things we could do. For example, a description of what lies in each folder of externals and what they are for may well be enough, followed by a list of objects. My students are _scared_ of Pd because it is so utterly different to anything else they have ever engaged with. A bit of documentation that isn't in Pd itself eases the pain somewhat.
A static web page will never be up-to-date since the pd externals folder is always a moving target. But it is better than nothing. It was really hard persuading students to learn Pd when Flossmanuals didn't exist. It's still hard, but it does open some doors to my students.
Ed
-Jonathan
.hc
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On 05/01/2013 02:47, Ed Kelly wrote:
Also notice that neither you nor I are the least bit interested in fixing these problems in the FLOSS manual, and we're especially not interested in taking it on as a long term project. Who does that leave? If it leaves anyone wouldn't their time be better spent fixing the doc problems listed on the tracker than etching in stone a description of a moving target?
Well, if you have to teach Pd to art students who are used to using Photoshop and Final Cut Pro (as I do) the FLOSS manual page is very useful to give them some idea of what the objects are. It may not be 100% accurate, but at least it is (only) a start. I do hope that the search mechanism replaces static docs conceptually, but here is why they should be kept.
Learning Pd from scratch is not easy unless you are already a computer scientist. "How do I know what the objects are called" is I agree, the wrong question in so many ways. However, 80% of my undergraduate students basically give up at that point if they can't find the answer, and probably 60% of my masters students, often after saying "I hate Pd". This question usually comes up in the first lesson. I could criticise them for this, except that there is an impression that Pd is "open" as well as open-source. Is it? Or is it highly elitist? I think it can be both, but I don't want to kick away the ladder...
Perhaps the problem lies more with "standards" for documentation across the whole community - it's never going to happen (remember Pdpedia?) because the Pd community can be somewhat anarchic. Hats off to Hans - making Pd-extended work is like nailing jelly to the wall I guess.
There are some small things we could do. For example, a description of what lies in each folder of externals and what they are for may well be enough, followed by a list of objects. My students are _scared_ of Pd because it is so utterly different to anything else they have ever engaged with. A bit of documentation that isn't in Pd itself eases the pain somewhat.
A static web page will never be up-to-date since the pd externals folder is always a moving target. But it is better than nothing. It was really hard persuading students to learn Pd when Flossmanuals didn't exist. It's still hard, but it does open some doors to my students.
Ed
-Jonathan
.hc
I agree this is something useful despite all that has been said. It's not perfect or up to date, but it's really better than nothing. It is also a bit easier to access for non-English speakers since you can translate theses lists (not the object names - yet ;) ) But Search and help-patches are limited to English for the moment.
pob
----- Original Message -----
From: Pierre-Olivier Boulant po.boulant@free.fr To: Ed Kelly morph_2016@yahoo.co.uk Cc: Jonathan Wilkes jancsika@yahoo.com; Hans-Christoph Steiner hans@at.or.at; Pd List pd-list@iem.at Sent: Saturday, January 5, 2013 5:46 AM Subject: Re: [PD] translate the Start Here! page
On 05/01/2013 02:47, Ed Kelly wrote:
Also notice that neither you nor I are the least bit interested in
fixing these
problems in the FLOSS manual, and we're especially not interested
in taking
it on as a long term project. Who does that leave? If it leaves
anyone
wouldn't their time be better spent fixing the doc problems listed
on the
tracker than etching in stone a description of a moving target?
Well, if you have to teach Pd to art students who are used to using
Photoshop and Final Cut Pro (as I do) the FLOSS manual page is very useful to give them some idea of what the objects are. It may not be 100% accurate, but at least it is (only) a start. I do hope that the search mechanism replaces static docs conceptually, but here is why they should be kept.
Learning Pd from scratch is not easy unless you are already a computer
scientist. "How do I know what the objects are called" is I agree, the wrong question in so many ways. However, 80% of my undergraduate students basically give up at that point if they can't find the answer, and probably 60% of my masters students, often after saying "I hate Pd". This question usually comes up in the first lesson. I could criticise them for this, except that there is an impression that Pd is "open" as well as open-source. Is it? Or is it highly elitist? I think it can be both, but I don't want to kick away the ladder...
Perhaps the problem lies more with "standards" for documentation
across the whole community - it's never going to happen (remember Pdpedia?) because the Pd community can be somewhat anarchic. Hats off to Hans - making Pd-extended work is like nailing jelly to the wall I guess.
There are some small things we could do. For example, a description of what
lies in each folder of externals and what they are for may well be enough, followed by a list of objects. My students are _scared_ of Pd because it is so utterly different to anything else they have ever engaged with. A bit of documentation that isn't in Pd itself eases the pain somewhat.
A static web page will never be up-to-date since the pd externals folder is
always a moving target. But it is better than nothing. It was really hard persuading students to learn Pd when Flossmanuals didn't exist. It's still hard, but it does open some doors to my students.
Ed
-Jonathan
.hc
I agree this is something useful despite all that has been said. It's not perfect or up to date, but it's really better than nothing. It is also a bit easier to access for non-English speakers since you can translate theses lists (not the object names - yet ;) )
But it's the Pd FLOSS manual object list-- and only that-- which I'm addressing. If it's not yet translated then it is _worse_ than using the search plugin, because it leaves out info about which objects belong to which libraries and is already out of date as to which objects are in Pd extended.
Please spend as much time as you want/can to maintain everything else in the Pd FLOSS manual, and please spend zero time "improving" the big out-of-date object list because that's time better spent working on the actual Pd documentation. Look at anything in the tracker that includes the word "documentation":
http://sourceforge.net/tracker/?group_id=55736&atid=478070&source=na...
But Search and help-patches are limited to English for the moment.
Search has already been translated to a couple of languages.
-Jonathan
pob
----- Original Message -----
From: Ed Kelly morph_2016@yahoo.co.uk To: Jonathan Wilkes jancsika@yahoo.com; Hans-Christoph Steiner hans@at.or.at Cc: Pd List pd-list@iem.at Sent: Friday, January 4, 2013 8:47 PM Subject: Re: [PD] translate the Start Here! page
Also notice that neither you nor I are the least bit interested in fixing
these
problems in the FLOSS manual, and we're especially not interested in
taking
it on as a long term project. Who does that leave? If it leaves anyone wouldn't their time be better spent fixing the doc problems listed on
the
tracker than etching in stone a description of a moving target?
Well, if you have to teach Pd to art students who are used to using Photoshop and Final Cut Pro (as I do) the FLOSS manual page is very useful to give them some idea of what the objects are. It may not be 100% accurate, but at least it is (only) a start. I do hope that the search mechanism replaces static docs conceptually, but here is why they should be kept.
Learning Pd from scratch is not easy unless you are already a computer scientist. "How do I know what the objects are called" is I agree, the wrong question in so many ways.
Pd is basically just rectangles containing words, connected by lines. Each box should do one thing and do it well, to draw from the unix philosophy. Lines connect the input of one box to another so that complex problems may be solved by combining many simple, clearly-defined building blocks to one another.
Aside from the particulars of controlling the flow of data through the diagram, what other question is there than, "How do I know what the objects are called?"
However, 80% of my undergraduate students basically give up at that point if they can't find the answer, and probably 60% of my masters students, often after saying "I hate Pd".
Of course they might also have just found out what happens when you try to click "Undo" more than once in a row. Or they projected a patch on a screen for a demo and tried to enlarge the patch by making the fonts bigger, and Pd mocked them by making a mess because well, they didn't tell Pd to also scale the x,y positions and Pd isn't about to make any assumption at all about what the user wants because then it would be coddling them.
Also they can't change the colors. Also in tk 8.4 the fonts hurt their eyes. Also the tk menus respond to clicks in a slightly different way than native tk menus. Also moving an array (which also is limited to black and white) not only causes dropouts but animates with speed similar to an Apple II. Also every time they load a soundfile they are in danger of a dropout.
Also patches look slightly different on different machines so that Alice may send perfectly designed patches to Bob but Bob sees overlapping text and wonders silently why Alice is so sloppy.
Also any time they consider improving any of this behavior they are faced with a graveyard of revisions by people much smarter than they are which are way more elegant than anything they'd ever come up with.
Pd _clearly_ hates them from their perspective. Provably, because as you said they're already using advanced software that has tons of quality documentation and teams of devs devoted to caring about how well-designed the interface actually is. And let's hope they don't come on this list and see the general ethos that while Pd is barebones, real men build patches from the ground up and eschew pre-fabbed solutions. (Again drawing from the unix philosophy.) Fine, but somehow that translates into a programming environment that's less accessible for people with vision problems, and a single undo history? That's absurd.
I wouldn't criticize them for not being Nelson Mandela.
This question usually comes up in the first lesson. I could criticise them for this, except that there is an impression that Pd is "open" as well as open-source. Is it? Or is it highly elitist? I think it can be both, but I don't want to kick away the ladder...
It's much simpler than all that.
A program that has a single undo history quite simply _should_ suck in the eyes of the beginner. It sucks because it ignores the small amount of memory a beginner has for visualizing in the language, and it sucks because it ignores the enormous power modern computers have to store this history for the user. Again, your students _know_ this from working with programs that require much more sophisticated command histories and deliver them flawlessly. They should rightly be suspicious of how much of their limited time this outlier software will actually require of them _before_ they can even start benefiting from its intended design.
And single-item undo is just one small example. Things like non-standard navigation within a comment, mode-changes with a single, subtle piece of visual feedback (the mouse cursor), and a lot else. (But it's not an endless list.)
Perhaps the problem lies more with "standards" for documentation across the whole community - it's never going to happen (remember Pdpedia?) because the Pd community can be somewhat anarchic. Hats off to Hans - making Pd-extended work is like nailing jelly to the wall I guess.
No need for standards. Write your help patches in any way you wish. If you want your objects to be found by category and look decent in the results of the search plugin (as well as respond meaningfully when "Autotips" is enabled), use [pd META], which you're already using because I bootstrapped that standard. It's done.
At this stage I'm mainly concerned with the quality of these "anarchist" patches. Here's another standard: if a help patch doesn't feature a clear example patch, description of what all xlets do (with descriptions of what all methods do), description of what all args do, then its a bug. Done:
http://sourceforge.net/tracker/?func=detail&aid=3597385&group_id=557...
Btw-- the most non-conformist library, unauthorized, already conforms to my "standard", which tells me we're not really talking about a standard but merely documentation quality.
There are some small things we could do. For example, a description of what lies in each folder of externals and what they are for may well be enough, followed by a list of objects.
Already done. In Pd-extended nightly build:
Click "Help" or <ctrl-h>
Click the "External Pd Libraries" link
View the "description of what lies in each folder of externals"
Click a link to get a list of objects, with a description of each object and link that
opens that object's help patch.
My students are _scared_ of Pd because it is so utterly different to anything else they have ever engaged with. A bit of documentation that isn't in Pd itself eases the pain somewhat.
If you can calm them down enough to click <ctrl-h> they will be greeted by the search plugin, and they will be tricked into believing they are looking at something less scary than Pd.
A static web page will never be up-to-date since the pd externals folder is always a moving target. But it is better than nothing.
I'm not comparing it to nothing. I'm comparing it to the search plugin.
It was really hard persuading students to learn Pd when Flossmanuals didn't exist. It's still hard, but it does open some doors to my students.
I'm only talking about the Object List in the Pd FLOSS manual.
-Jonathan
Ed
-Jonathan
.hc
_______________________________________________ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
OK, no need to fight. This is about a version of Pd-extended that has been a very long time coming, that had many issues to resolve, that went offline and was unavailable at the start of the workshops I teach. I also can't get my students to download a version of Pd-extended that isn't finished and won't run on their machine. This is their first experience of programming. They'll give up straight away!
It sounds like it will be finished soon, and then we can all relax. Until then anything I can do to help my students achieve some traction with Pd, including pointing to a list of objects - until search is finished AND in the release version, is pedagogically valid.
PS - I think they learned more this year than they did last year.
best, Ed
Gemnotes-0.2: Live music notation for Pure Data, now with dynamics! http://sharktracks.co.uk/
----- Original Message -----
From: Jonathan Wilkes jancsika@yahoo.com To: Ed Kelly morph_2016@yahoo.co.uk; Hans-Christoph Steiner hans@at.or.at Cc: Pd List pd-list@iem.at Sent: Saturday, 5 January 2013, 17:37 Subject: Re: [PD] translate the Start Here! page
----- Original Message -----
From: Ed Kelly morph_2016@yahoo.co.uk To: Jonathan Wilkes jancsika@yahoo.com; Hans-Christoph Steiner
Cc: Pd List pd-list@iem.at Sent: Friday, January 4, 2013 8:47 PM Subject: Re: [PD] translate the Start Here! page
Also notice that neither you nor I are the least bit interested in
fixing
these
problems in the FLOSS manual, and we're especially not interested
in
taking
it on as a long term project. Who does that leave? If it leaves
anyone
wouldn't their time be better spent fixing the doc problems listed
on
the
tracker than etching in stone a description of a moving target?
Well, if you have to teach Pd to art students who are used to using
Photoshop
and Final Cut Pro (as I do) the FLOSS manual page is very useful to give
them
some idea of what the objects are. It may not be 100% accurate, but at
least it
is (only) a start. I do hope that the search mechanism replaces static docs
conceptually, but here is why they should be kept.
Learning Pd from scratch is not easy unless you are already a computer scientist. "How do I know what the objects are called" is I
agree, the
wrong question in so many ways.
Pd is basically just rectangles containing words, connected by lines. Each box should do one thing and do it well, to draw from the unix philosophy. Lines connect the input of one box to another so that complex problems may be solved by combining many simple, clearly-defined building blocks to one another.
Aside from the particulars of controlling the flow of data through the diagram, what other question is there than, "How do I know what the objects are called?"
However, 80% of my undergraduate students basically give up at that point if they can't find the answer, and
probably
60% of my masters students, often after saying "I hate Pd".
Of course they might also have just found out what happens when you try to click "Undo" more than once in a row. Or they projected a patch on a screen for a demo and tried to enlarge the patch by making the fonts bigger, and Pd mocked them by making a mess because well, they didn't tell Pd to also scale the x,y positions and Pd isn't about to make any assumption at all about what the user wants because then it would be coddling them.
Also they can't change the colors. Also in tk 8.4 the fonts hurt their eyes. Also the tk menus respond to clicks in a slightly different way than native tk menus. Also moving an array (which also is limited to black and white) not only causes dropouts but animates with speed similar to an Apple II. Also every time they load a soundfile they are in danger of a dropout.
Also patches look slightly different on different machines so that Alice may send perfectly designed patches to Bob but Bob sees overlapping text and wonders silently why Alice is so sloppy.
Also any time they consider improving any of this behavior they are faced with a graveyard of revisions by people much smarter than they are which are way more elegant than anything they'd ever come up with.
Pd _clearly_ hates them from their perspective. Provably, because as you said they're already using advanced software that has tons of quality documentation and teams of devs devoted to caring about how well-designed the interface actually is. And let's hope they don't come on this list and see the general ethos that while Pd is barebones, real men build patches from the ground up and eschew pre-fabbed solutions. (Again drawing from the unix philosophy.) Fine, but somehow that translates into a programming environment that's less accessible for people with vision problems, and a single undo history? That's absurd.
I wouldn't criticize them for not being Nelson Mandela.
This question usually comes up in the first lesson. I could criticise them for
this,
except that there is an impression that Pd is "open" as well as open-source. Is it? Or is it highly elitist? I think it can be both, but I don't want to kick away the ladder...
It's much simpler than all that.
A program that has a single undo history quite simply _should_ suck in the eyes of the beginner. It sucks because it ignores the small amount of memory a beginner has for visualizing in the language, and it sucks because it ignores the enormous power modern computers have to store this history for the user. Again, your students _know_ this from working with programs that require much more sophisticated command histories and deliver them flawlessly. They should rightly be suspicious of how much of their limited time this outlier software will actually require of them _before_ they can even start benefiting from its intended design.
And single-item undo is just one small example. Things like non-standard navigation within a comment, mode-changes with a single, subtle piece of visual feedback (the mouse cursor), and a lot else. (But it's not an endless list.)
Perhaps the problem lies more with "standards" for documentation across the whole community - it's never going to happen (remember
Pdpedia?)
because the Pd community can be somewhat anarchic. Hats off to Hans -
making
Pd-extended work is like nailing jelly to the wall I guess.
No need for standards. Write your help patches in any way you wish. If you want your objects to be found by category and look decent in the results of the search plugin (as well as respond meaningfully when "Autotips" is enabled), use [pd META], which you're already using because I bootstrapped that standard. It's done.
At this stage I'm mainly concerned with the quality of these "anarchist" patches. Here's another standard: if a help patch doesn't feature a clear example patch, description of what all xlets do (with descriptions of what all methods do), description of what all args do, then its a bug. Done:
http://sourceforge.net/tracker/?func=detail&aid=3597385&group_id=557...
Btw-- the most non-conformist library, unauthorized, already conforms to my "standard", which tells me we're not really talking about a standard but merely documentation quality.
There are some small things we could do. For example, a description of what
lies
in each folder of externals and what they are for may well be enough,
followed
by a list of objects.
Already done. In Pd-extended nightly build:
Click "Help" or <ctrl-h>
Click the "External Pd Libraries" link
View the "description of what lies in each folder of externals"
Click a link to get a list of objects, with a description of each object and
link that opens that object's help patch.
My students are _scared_ of Pd because it is so utterly different to anything else they have ever engaged with. A bit of
documentation
that isn't in Pd itself eases the pain somewhat.
If you can calm them down enough to click <ctrl-h> they will be greeted by the search plugin, and they will be tricked into believing they are looking at something less scary than Pd.
A static web page will never be up-to-date since the pd externals folder is
always a moving target. But it is better than nothing.
I'm not comparing it to nothing. I'm comparing it to the search plugin.
It was really hard persuading students to learn Pd when Flossmanuals didn't exist.
It's
still hard, but it does open some doors to my students.
I'm only talking about the Object List in the Pd FLOSS manual.
-Jonathan
Ed
-Jonathan
.hc
_______________________________________________ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
----- Original Message -----
From: Ed Kelly morph_2016@yahoo.co.uk To: Jonathan Wilkes jancsika@yahoo.com; Hans-Christoph Steiner hans@at.or.at Cc: Pd List pd-list@iem.at Sent: Saturday, January 5, 2013 5:18 PM Subject: Re: [PD] translate the Start Here! page
OK, no need to fight. This is about a version of Pd-extended that has been a very long time coming, that had many issues to resolve, that went offline and was unavailable at the start of the workshops I teach. I also can't get my students to download a version of Pd-extended that isn't finished and won't run on their machine. This is their first experience of programming. They'll give up straight away!
Of course. I'm just giving you a beginner's perspective; it's my own memory of that perspective that drives me to work on tools which are currently only marginally useful to me personally. The supermajority of discontent among your students tells me that this perspective hasn't changed much. By far, that is currently the fault of the software-- the documentation is currently too slim and core pd building blocks (and interface) too crude for the question "how do I find more objects" to be anything like an ancillary question.
A static out-of-date list is better than nothing, but as far as potential dev energy I'd really rather see that put into core docs like the ones listed on the bug tracker, which are extremely lacking. That FLOSS list will hopefully become obsolete, but the help docs won't-- even if they're dropped from Pd-extended they're still publicly available.
-Jonathan
On Jan 5, 2013, at 6:22 PM, Jonathan Wilkes wrote:
----- Original Message -----
From: Ed Kelly morph_2016@yahoo.co.uk To: Jonathan Wilkes jancsika@yahoo.com; Hans-Christoph Steiner hans@at.or.at Cc: Pd List pd-list@iem.at Sent: Saturday, January 5, 2013 5:18 PM Subject: Re: [PD] translate the Start Here! page
OK, no need to fight. This is about a version of Pd-extended that has been a very long time coming, that had many issues to resolve, that went offline and was unavailable at the start of the workshops I teach. I also can't get my students to download a version of Pd-extended that isn't finished and won't run on their machine. This is their first experience of programming. They'll give up straight away!
Of course. I'm just giving you a beginner's perspective; it's my own memory of that perspective that drives me to work on tools which are currently only marginally useful to me personally. The supermajority of discontent among your students tells me that this perspective hasn't changed much. By far, that is currently the fault of the software-- the documentation is currently too slim and core pd building blocks (and interface) too crude for the question "how do I find more objects" to be anything like an ancillary question.
A static out-of-date list is better than nothing, but as far as potential dev energy I'd really rather see that put into core docs like the ones listed on the bug tracker, which are extremely lacking. That FLOSS list will hopefully become obsolete, but the help docs won't-- even if they're dropped from Pd-extended they're still publicly available.
-Jonathan
While I have agreed and disagreed with various points in this discussion, I think Jonathan's two paragraphs above sum up my feelings on this topic too. Jonathan has put together a really great system for help from the meta data to the search plugin, now we need to put actual content and meta data in our help patches and it'll all be findable in a multitude of ways. All this could even be used to generate the static listing in the FLOSS manuals: just take the object name, then get the library and description from the [pd META].
.hc
On 2013-01-05 22:36, Hans-Christoph Steiner wrote:
On Jan 5, 2013, at 6:22 PM, Jonathan Wilkes wrote:
----- Original Message -----
From: Ed Kelly morph_2016@yahoo.co.uk To: Jonathan Wilkes jancsika@yahoo.com; Hans-Christoph Steiner hans@at.or.at Cc: Pd List pd-list@iem.at Sent: Saturday, January 5, 2013 5:18 PM Subject: Re: [PD] translate the Start Here! page
OK, no need to fight. This is about a version of Pd-extended that has been a very long time coming, that had many issues to resolve, that went offline and was unavailable at the start of the workshops I teach. I also can't get my students to download a version of Pd-extended that isn't finished and won't run on their machine. This is their first experience of programming. They'll give up straight away!
Of course. I'm just giving you a beginner's perspective; it's my own memory of that perspective that drives me to work on tools which are currently only marginally useful to me personally. The supermajority of discontent among your students tells me that this perspective hasn't changed much. By far, that is currently the fault of the software-- the documentation is currently too slim and core pd building blocks (and interface) too crude for the question "how do I find more objects" to be anything like an ancillary question.
A static out-of-date list is better than nothing, but as far as potential dev energy I'd really rather see that put into core docs like the ones listed on the bug tracker, which are extremely lacking. That FLOSS list will hopefully become obsolete, but the help docs won't-- even if they're dropped from Pd-extended they're still publicly available.
-Jonathan
While I have agreed and disagreed with various points in this discussion, I think Jonathan's two paragraphs above sum up my feelings on this topic too. Jonathan has put together a really great system for help from the meta data to the search plugin, now we need to put actual content and meta data in our help patches and it'll all be findable in a multitude of ways. All this could even be used to generate the static listing in the FLOSS manuals: just take the object name, then get the library and description from the [pd META].
Yeah, and we need the spec for [Pd META] to be known. For devs maybe en entry in the externals HOWTO?
Martin
----- Original Message -----
From: Martin Peach martin.peach@sympatico.ca To: Hans-Christoph Steiner hans@at.or.at Cc: Jonathan Wilkes jancsika@yahoo.com; Pd List pd-list@iem.at Sent: Saturday, January 5, 2013 11:23 PM Subject: Re: [PD] translate the Start Here! page
On 2013-01-05 22:36, Hans-Christoph Steiner wrote:
On Jan 5, 2013, at 6:22 PM, Jonathan Wilkes wrote:
----- Original Message -----
From: Ed Kelly morph_2016@yahoo.co.uk To: Jonathan Wilkes jancsika@yahoo.com; Hans-Christoph
Steiner hans@at.or.at
Cc: Pd List pd-list@iem.at Sent: Saturday, January 5, 2013 5:18 PM Subject: Re: [PD] translate the Start Here! page
OK, no need to fight. This is about a version of Pd-extended that
has been a
very long time coming, that had many issues to resolve, that went
offline and
was unavailable at the start of the workshops I teach. I also
can't get my
students to download a version of Pd-extended that isn't
finished and
won't run on their machine. This is their first experience of
programming.
They'll give up straight away!
Of course. I'm just giving you a beginner's perspective;
it's my own
memory of that perspective that drives me to work on tools which are
currently
only marginally useful to me personally. The supermajority of
discontent
among your students tells me that this perspective hasn't changed
much.
By far, that is currently the fault of the software-- the documentation
is
currently too slim and core pd building blocks (and interface) too
crude
for the question "how do I find more objects" to be anything
like an ancillary
question.
A static out-of-date list is better than nothing, but as far as
potential dev
energy I'd really rather see that put into core docs like the ones
listed
on the bug tracker, which are extremely lacking. That FLOSS list will
hopefully
become obsolete, but the help docs won't-- even if they're
dropped from
Pd-extended they're still publicly available.
-Jonathan
While I have agreed and disagreed with various points in this discussion, I
think Jonathan's two paragraphs above sum up my feelings on this topic too. Jonathan has put together a really great system for help from the meta data to the search plugin, now we need to put actual content and meta data in our help patches and it'll all be findable in a multitude of ways. All this could even be used to generate the static listing in the FLOSS manuals: just take the object name, then get the library and description from the [pd META].
Yeah, and we need the spec for [Pd META] to be known.
doc/5.reference/all_about_pd_META.pd
I indicate GPL licenses as "GPL v2" or "GPL v3" because the original search engine was written in Pd and it was easier to parse that way. But I think the standard is "GPLv2" so this should probably be mass replaced at some point.
For devs maybe en entry in the externals HOWTO?
Martin
----- Original Message -----
From: Martin Peach martin.peach@sympatico.ca To: Hans-Christoph Steiner hans@at.or.at Cc: Pd List pd-list@iem.at Sent: Sunday, 6 January 2013, 4:23 Subject: Re: [PD] translate the Start Here! page
On 2013-01-05 22:36, Hans-Christoph Steiner wrote:
On Jan 5, 2013, at 6:22 PM, Jonathan Wilkes wrote:
----- Original Message -----
From: Ed Kelly morph_2016@yahoo.co.uk To: Jonathan Wilkes jancsika@yahoo.com; Hans-Christoph
Steiner hans@at.or.at
Cc: Pd List pd-list@iem.at Sent: Saturday, January 5, 2013 5:18 PM Subject: Re: [PD] translate the Start Here! page
OK, no need to fight. This is about a version of Pd-extended that
has been a
very long time coming, that had many issues to resolve, that went
offline and
was unavailable at the start of the workshops I teach. I also
can't get my
students to download a version of Pd-extended that isn't
finished and
won't run on their machine. This is their first experience of
programming.
They'll give up straight away!
Of course. I'm just giving you a beginner's perspective;
it's my own
memory of that perspective that drives me to work on tools which are
currently
only marginally useful to me personally. The supermajority of
discontent
among your students tells me that this perspective hasn't changed
much.
By far, that is currently the fault of the software-- the documentation
is
currently too slim and core pd building blocks (and interface) too
crude
for the question "how do I find more objects" to be anything
like an ancillary
question.
A static out-of-date list is better than nothing, but as far as
potential dev
energy I'd really rather see that put into core docs like the ones
listed
on the bug tracker, which are extremely lacking. That FLOSS list will
hopefully
become obsolete, but the help docs won't-- even if they're
dropped from
Pd-extended they're still publicly available.
-Jonathan
While I have agreed and disagreed with various points in this discussion, I
think Jonathan's two paragraphs above sum up my feelings on this topic too. Jonathan has put together a really great system for help from the meta data to the search plugin, now we need to put actual content and meta data in our help patches and it'll all be findable in a multitude of ways. All this could even be used to generate the static listing in the FLOSS manuals: just take the object name, then get the library and description from the [pd META].
Yeah, and we need the spec for [Pd META] to be known. For devs maybe en entry in the externals HOWTO?
There are some great ideas here that need further investigation.
Generation of static web documentation from [Pd META]. It's the only way such online documentation could be kept up-to-date as Pd is indeed a "moving target"
This would require [Pd META] to contain more information than just the library name, author and version. Since this is already universally applied across Pd extended, it's ready to be modified and extended. Does this sound like a good idea?
Ed
Martin
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On 01/06/2013 07:28 PM, Ed Kelly wrote:
----- Original Message -----
From: Martin Peach martin.peach@sympatico.ca To: Hans-Christoph Steiner hans@at.or.at Cc: Pd List pd-list@iem.at Sent: Sunday, 6 January 2013, 4:23 Subject: Re: [PD] translate the Start Here! page
On 2013-01-05 22:36, Hans-Christoph Steiner wrote:
On Jan 5, 2013, at 6:22 PM, Jonathan Wilkes wrote:
----- Original Message -----
From: Ed Kelly morph_2016@yahoo.co.uk To: Jonathan Wilkes jancsika@yahoo.com; Hans-Christoph
Steiner hans@at.or.at
Cc: Pd List pd-list@iem.at Sent: Saturday, January 5, 2013 5:18 PM Subject: Re: [PD] translate the Start Here! page
OK, no need to fight. This is about a version of Pd-extended that
has been a
very long time coming, that had many issues to resolve, that went
offline and
was unavailable at the start of the workshops I teach. I also
can't get my
students to download a version of Pd-extended that isn't
finished and
won't run on their machine. This is their first experience of
programming.
They'll give up straight away!
Of course. I'm just giving you a beginner's perspective;
it's my own
memory of that perspective that drives me to work on tools which are
currently
only marginally useful to me personally. The supermajority of
discontent
among your students tells me that this perspective hasn't changed
much.
By far, that is currently the fault of the software-- the documentation
is
currently too slim and core pd building blocks (and interface) too
crude
for the question "how do I find more objects" to be anything
like an ancillary
question.
A static out-of-date list is better than nothing, but as far as
potential dev
energy I'd really rather see that put into core docs like the ones
listed
on the bug tracker, which are extremely lacking. That FLOSS list will
hopefully
become obsolete, but the help docs won't-- even if they're
dropped from
Pd-extended they're still publicly available.
-Jonathan
While I have agreed and disagreed with various points in this discussion, I
think Jonathan's two paragraphs above sum up my feelings on this topic too.
Jonathan has put together a really great system for help from the meta data to the search plugin, now we need to put actual content and meta data in our help patches and it'll all be findable in a multitude of ways. All this could even be used to generate the static listing in the FLOSS manuals: just take the object name, then get the library and description from the [pd META].Yeah, and we need the spec for [Pd META] to be known. For devs maybe en entry in the externals HOWTO?
There are some great ideas here that need further investigation.
Generation of static web documentation from [Pd META]. It's the only way such online documentation could be kept up-to-date as Pd is indeed a "moving target"
This would require [Pd META] to contain more information than just the library name, author and version. Since this is already universally applied across Pd extended, it's ready to be modified and extended. Does this sound like a good idea?
Yes it does, so much so that Jonathan has already implemented the extra meta data that you are talking about :) There is inlets and outlets, description, and more.
.hc
----- Original Message -----
From: Ed Kelly morph_2016@yahoo.co.uk To: Martin Peach martin.peach@sympatico.ca; Hans-Christoph Steiner hans@at.or.at Cc: Pd List pd-list@iem.at Sent: Sunday, January 6, 2013 7:28 PM Subject: Re: [PD] translate the Start Here! page
[...]
- This would require [Pd META] to contain more information than just the
library name, author and version. Since this is already universally applied across Pd extended, it's ready to be modified and extended. Does this sound like a good idea?
Do you still maintain ekext? If so just click on the [pd META] subpatch inside one of your help patches and you will see what it contains.
-Jonathan
Ed
Martin
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
for whom it interests, I was the one putting that list up - a short
version of my own xls file made through copy-pasting - and I always agreed
that the fixed format was the worse way to nail the "moving target". but I
have no knowledge to do it better, so it had to be done that way, and
apparently many people did used it (even though it was never complete).
if possible, I can help in any way of improving this reference, including
taking it down. the only thing I won't do is more copy-pasting, because it
is really irrelevant. but as I don't have any batching knowledge, the best
I can do is to check for libraries missing meta data (including mine),
etc. Or do portuguese desserts for whoever wants to work
(http://tinyurl.com/blyqgsc).
for the categorization of the pd objects, I would suggest something else:
to expand the list of categories, either with more categories, or with
subcategories. the list from vanilla is very general, even for the vanilla
objects. To have few categories with too many objects in them isn't really
a big help in sorting out the objects. But that would be the discussion of
a new thread.
On Jan 5, 2013, at 6:22 PM, Jonathan Wilkes wrote:
----- Original Message -----
From: Ed Kelly morph_2016@yahoo.co.uk To: Jonathan Wilkes jancsika@yahoo.com; Hans-Christoph Steiner
hans@at.or.at Cc: Pd List pd-list@iem.at Sent: Saturday, January 5, 2013 5:18 PM Subject: Re: [PD] translate the Start Here! pageOK, no need to fight. This is about a version of Pd-extended that has
been a very long time coming, that had many issues to resolve, that went
offline and was unavailable at the start of the workshops I teach. I also can't
get my students to download a version of Pd-extended that isn't finished and won't run on their machine. This is their first experience of
programming. They'll give up straight away!Of course. I'm just giving you a beginner's perspective; it's my own memory of that perspective that drives me to work on tools which are
currently only marginally useful to me personally. The supermajority of
discontent among your students tells me that this perspective hasn't changed much. By far, that is currently the fault of the software-- the documentation
is currently too slim and core pd building blocks (and interface) too crude for the question "how do I find more objects" to be anything like an
ancillary question.A static out-of-date list is better than nothing, but as far as
potential dev energy I'd really rather see that put into core docs like the ones
listed on the bug tracker, which are extremely lacking. That FLOSS list will
hopefully become obsolete, but the help docs won't-- even if they're dropped from Pd-extended they're still publicly available.-Jonathan
While I have agreed and disagreed with various points in this
discussion, I think Jonathan's two paragraphs above sum up my feelings
on this topic too. Jonathan has put together a really great system for
help from the meta data to the search plugin, now we need to put actual
content and meta data in our help patches and it'll all be findable in a
multitude of ways. All this could even be used to generate the static
listing in the FLOSS manuals: just take the object name, then get the
library and description from the [pd META]..hc
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
----- Original Message -----
From: João Pais jmmmpais@googlemail.com To: Jonathan Wilkes jancsika@yahoo.com; Hans-Christoph Steiner hans@at.or.at Cc: Pd List pd-list@iem.at Sent: Monday, January 7, 2013 4:54 AM Subject: Re: [PD] translate the Start Here! page
for whom it interests, I was the one putting that list up - a short version of my own xls file made through copy-pasting - and I always agreed that the fixed format was the worse way to nail the "moving target". but I have no knowledge to do it better, so it had to be done that way, and apparently many people did used it (even though it was never complete). if possible, I can help in any way of improving this reference, including taking it down. the only thing I won't do is more copy-pasting, because it is really irrelevant. but as I don't have any batching knowledge, the best I can do is to check for libraries missing meta data (including mine), etc. Or do portuguese desserts for whoever wants to work (http://tinyurl.com/blyqgsc).
for the categorization of the pd objects, I would suggest something else: to expand the list of categories, either with more categories, or with subcategories. the list from vanilla is very general, even for the vanilla objects. To have few categories with too many objects in them isn't really a big help in sorting out the objects. But that would be the discussion of a new thread.
You can see the categories if you scroll down to the bottom of the search plugin. They aren't hierarchical so there's no need for sub-categories.
These are just categories I came up with off the top of my head. Feel free to suggest additions, deletions, better descriptions, or any objects I may have missed.
-Jonathan
On Jan 5, 2013, at 6:22 PM, Jonathan Wilkes wrote:
----- Original Message -----
From: Ed Kelly morph_2016@yahoo.co.uk To: Jonathan Wilkes jancsika@yahoo.com; Hans-Christoph
Steiner hans@at.or.at
Cc: Pd List pd-list@iem.at Sent: Saturday, January 5, 2013 5:18 PM Subject: Re: [PD] translate the Start Here! page
OK, no need to fight. This is about a version of Pd-extended that
has been a
very long time coming, that had many issues to resolve, that went
offline and
was unavailable at the start of the workshops I teach. I also
can't get my
students to download a version of Pd-extended that isn't
finished and
won't run on their machine. This is their first experience of
programming.
They'll give up straight away!
Of course. I'm just giving you a beginner's perspective;
it's my own
memory of that perspective that drives me to work on tools which are
currently
only marginally useful to me personally. The supermajority of
discontent
among your students tells me that this perspective hasn't changed
much.
By far, that is currently the fault of the software-- the documentation
is
currently too slim and core pd building blocks (and interface) too
crude
for the question "how do I find more objects" to be anything
like an ancillary
question.
A static out-of-date list is better than nothing, but as far as
potential dev
energy I'd really rather see that put into core docs like the ones
listed
on the bug tracker, which are extremely lacking. That FLOSS list will
hopefully
become obsolete, but the help docs won't-- even if they're
dropped from
Pd-extended they're still publicly available.
-Jonathan
While I have agreed and disagreed with various points in this discussion, I
think Jonathan's two paragraphs above sum up my feelings on this topic too. Jonathan has put together a really great system for help from the meta data to the search plugin, now we need to put actual content and meta data in our help patches and it'll all be findable in a multitude of ways. All this could even be used to generate the static listing in the FLOSS manuals: just take the object name, then get the library and description from the [pd META].
.hc
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
--Friedenstr. 58 10249 Berlin (Deutschland) Tel +49 30 42020091 | Mob +49 162 6843570 Studio +49 30 69509190 jmmmpais@googlemail.com | skype: jmmmpjmmmp
You can see the categories if you scroll down to the bottom of the
search plugin. They aren't hierarchical so there's no need for sub-categories.These are just categories I came up with off the top of my head. Feel
free to suggest additions, deletions, better descriptions, or any objects I may
have missed.
I'll do that.
is there a way of reporting which libraries are missing the meta data? I
can try to ask their authors, or fill it in myself. starting with the
jmmmp library, I know where that guy lives.
João
----- Original Message -----
From: João Pais jmmmpais@googlemail.com To: Hans-Christoph Steiner hans@at.or.at; Jonathan Wilkes jancsika@yahoo.com Cc: Pd List pd-list@iem.at Sent: Monday, January 7, 2013 11:44 AM Subject: Re: [PD] translate the Start Here! page
You can see the categories if you scroll down to the bottom of the search
plugin.
They aren't hierarchical so there's no need for sub-categories.
These are just categories I came up with off the top of my head. Feel free
to
suggest additions, deletions, better descriptions, or any objects I may
have
missed.
I'll do that.
is there a way of reporting which libraries are missing the meta data? I can try to ask their authors, or fill it in myself.
If you're talking about LIBNAME-meta.pd, I'm not sure what the spec is for that. Looks something like this:
NAME libname DESCRIPTION short description of library VERSION 0.1 or whatever AUTHOR Foo Bar
But why do we need "NAME"? The library name is just the directory name. Also, some of the old ones have a "META blah blah" comment and I'm not sure what its purpose is.
But if you're talking missing the [pd META] inside each OBJECT-help.pd, put those as bugs on the tracker. Make sure to check it first as I've already added several.
-Jonathan
starting with the jmmmp library, I know where that guy lives.
João
May I make a suggestion?
If PD Meta contained a list of objects, and a short description of each object's function, it could be dynamically parsed into an XML document, the PD object list we've been arguing about in FLOSSmanuals could be generated by a PHP script, and so always up-to-date. It could be part of the autobuild process for pd-extended to generate this file.
Ed Gemnotes-0.2: Live music notation for Pure Data, now with dynamics! http://sharktracks.co.uk/
From: Jonathan Wilkes jancsika@yahoo.com To: João Pais jmmmpais@googlemail.com; Hans-Christoph Steiner hans@at.or.at Cc: Pd List pd-list@iem.at Sent: Monday, 7 January 2013, 22:23 Subject: Re: [PD] translate the Start Here! page
----- Original Message -----
From: João Pais jmmmpais@googlemail.com To: Hans-Christoph Steiner hans@at.or.at; Jonathan Wilkes jancsika@yahoo.com Cc: Pd List pd-list@iem.at Sent: Monday, January 7, 2013 11:44 AM Subject: Re: [PD] translate the Start Here! page
You can see the categories if you scroll down to the bottom of the search
plugin.
They aren't hierarchical so there's no need for sub-categories.
These are just categories I came up with off the top of my head. Feel free
to
suggest additions, deletions, better descriptions, or any objects I may
have
missed.
I'll do that.
is there a way of reporting which libraries are missing the meta data? I can try to ask their authors, or fill it in myself.
If you're talking about LIBNAME-meta.pd, I'm not sure what the spec is for that. Looks something like this:
NAME libname DESCRIPTION short description of library VERSION 0.1 or whatever AUTHOR Foo Bar
But why do we need "NAME"? The library name is just the directory name. Also, some of the old ones have a "META blah blah" comment and I'm not sure what its purpose is.
But if you're talking missing the [pd META] inside each OBJECT-help.pd, put those as bugs on the tracker. Make sure to check it first as I've already added several.
-Jonathan
starting with the jmmmp library, I know where that guy lives.
João
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
From: Ed Kelly morph_2016@yahoo.co.uk To: Jonathan Wilkes jancsika@yahoo.com; João Pais jmmmpais@googlemail.com; Hans-Christoph Steiner hans@at.or.at Cc: Pd List pd-list@iem.at Sent: Monday, January 7, 2013 5:48 PM Subject: Re: [PD] translate the Start Here! page
May I make a suggestion?
If PD Meta contained a list of objects, and a short description of each object's function, it could be dynamically parsed into an XML document, the PD object list we've been arguing about in FLOSSmanuals could be generated by a PHP script, and so always up-to-date. It could be part of the autobuild process for pd-extended to generate this file.
To generate such a libname-meta.pd in the first place you'd have to parse each *-help.pd inside the libdir for the "DESCRIPTION values" comment; it's one less step to write those results directly into the XML document.
Btw-- if you do that, keep in mind that messages in the pd file format can span multiple lines, so make sure you regsub the file as a whole (or the [pd META] subpatch) to grab everything from the TAG to the un-escaped semicolon.
-Jonathan
Ed Gemnotes-0.2: Live music notation for Pure Data, now with dynamics! http://sharktracks.co.uk/
From: Jonathan Wilkes jancsika@yahoo.com To: João Pais jmmmpais@googlemail.com; Hans-Christoph Steiner hans@at.or.at Cc: Pd List pd-list@iem.at Sent: Monday, 7 January 2013, 22:23 Subject: Re: [PD] translate the Start Here! page
----- Original Message -----
From: João Pais jmmmpais@googlemail.com To: Hans-Christoph Steiner hans@at.or.at; Jonathan Wilkes jancsika@yahoo.com Cc: Pd List pd-list@iem.at Sent: Monday, January 7, 2013 11:44 AM Subject: Re: [PD] translate the Start
Here! page
You can see the categories if you scroll down to the bottom of the search
plugin.
They aren't hierarchical so there's no need for sub-categories.
These are just categories I came up with off the top of my head. Feel free
to
suggest additions, deletions, better descriptions, or any objects I may
have
missed.
I'll do that.
is there a way of reporting which libraries are missing the meta data? I can try to ask their authors, or fill it in myself.
If you're talking about LIBNAME-meta.pd, I'm not sure what the spec is for that. Looks something like this:
NAME libname DESCRIPTION short description of library VERSION 0.1 or whatever AUTHOR Foo Bar
But why do we need "NAME"? The library name is just the directory name.
Also, some of the old ones have a "META blah blah" comment
and I'm not sure what its purpose is.
But if you're talking missing the [pd META] inside each OBJECT-help.pd, put those as bugs on the tracker. Make sure to check it first as I've already added several.
-Jonathan
starting with the jmmmp library, I know where that guy lives.
João
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On Jan 7, 2013, at 6:43 PM, Jonathan Wilkes wrote:
From: Ed Kelly morph_2016@yahoo.co.uk To: Jonathan Wilkes jancsika@yahoo.com; João Pais jmmmpais@googlemail.com; Hans-Christoph Steiner hans@at.or.at Cc: Pd List pd-list@iem.at Sent: Monday, January 7, 2013 5:48 PM Subject: Re: [PD] translate the Start Here! page
May I make a suggestion?
If PD Meta contained a list of objects, and a short description of each object's function, it could be dynamically parsed into an XML document, the PD object list we've been arguing about in FLOSSmanuals could be generated by a PHP script, and so always up-to-date. It could be part of the autobuild process for pd-extended to generate this file.
To generate such a libname-meta.pd in the first place you'd have to parse each *-help.pd inside the libdir for the "DESCRIPTION values" comment; it's one less step to write those results directly into the XML document.
Btw-- if you do that, keep in mind that messages in the pd file format can span multiple lines, so make sure you regsub the file as a whole (or the [pd META] subpatch) to grab everything from the TAG to the un-escaped semicolon.
I just did some of this parsing in python for getting translation strings from patches:
regex = re.compile('#X text [0-9]+ [0-9]+ ([^;]*);', re.MULTILINE | re.DOTALL) matches = [m.groups() for m in regex.finditer(text)]
nonewlines = re.compile('\n', re.MULTILINE) nobackslashes = re.compile(' \\', re.MULTILINE) escapedoublequote = re.compile('[^\\]"', re.MULTILINE)
ids = [] for m in matches: if m: chunk = m[0] chunk = re.sub(nonewlines, ' ', chunk) chunk = re.sub(nobackslashes, '', chunk) chunk = re.sub(escapedoublequote, '\"', chunk) if chunk not in ids: ids.append(chunk)
http://pure-data.svn.sourceforge.net/viewvc/pure-data/trunk/doc/tutorials/st...
.hc