I have several abstractions for which there should logically be one common helpfile explaining them all at once. How do I specify the name of the helpfile I want to have opened?
I want to do like class_sethelpsymbol() but for abstractions instead of externals.
(Have I asked that question before? I don't remember)
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
Easiest hack would be to copy the same file to the corresponding abs-help.pdfiles. But that would be annoying to update.
~Kyle
On 1/4/07, Mathieu Bouchard matju@artengine.ca wrote:
I have several abstractions for which there should logically be one common helpfile explaining them all at once. How do I specify the name of the helpfile I want to have opened?
I want to do like class_sethelpsymbol() but for abstractions instead of externals.
(Have I asked that question before? I don't remember)
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On Fri, 5 Jan 2007, Kyle Klipowicz wrote:
Easiest hack would be to copy the same file to the corresponding abs-help.pdfiles. But that would be annoying to update.
Yes, or symlinks, but those work only on Linux and OSX and everything else except Windows. Oh well.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
The PDDP standard for this is to have every object have its own help
file, then have a shared "all_about" patch for the common parts. You
can link to that other patch using pddp/open or pddp/pddplink.
Each object's help patch should have an example that is specific to
that object. If there aren't different examples, then I don't see
the point of having different objects...
.hc
On Jan 4, 2007, at 9:55 PM, Mathieu Bouchard wrote:
I have several abstractions for which there should logically be one
common helpfile explaining them all at once. How do I specify the
name of the helpfile I want to have opened?I want to do like class_sethelpsymbol() but for abstractions
instead of externals.(Have I asked that question before? I don't remember)
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC
Canada_______________________________________________ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
"[W]e have invented the technology to eliminate scarcity, but we are
deliberately throwing it away to benefit those who profit from
scarcity." -John Gilmore
This is a good point.
I wish that individual files would have their own separate help files quite often. Say, when getting help for ctrlin or midiin (or others of their ilk), it's quite annoying to new (and more seasoned) users to get detailed information on these objects.
Help files should be like a man page with a working set of embedded examples.
~Kyle
On 1/5/07, Hans-Christoph Steiner hans@eds.org wrote:
The PDDP standard for this is to have every object have its own help file, then have a shared "all_about" patch for the common parts. You can link to that other patch using pddp/open or pddp/pddplink.
Each object's help patch should have an example that is specific to that object. If there aren't different examples, then I don't see the point of having different objects...
.hc
On Jan 4, 2007, at 9:55 PM, Mathieu Bouchard wrote:
I have several abstractions for which there should logically be one common helpfile explaining them all at once. How do I specify the name of the helpfile I want to have opened?
I want to do like class_sethelpsymbol() but for abstractions instead of externals.
(Have I asked that question before? I don't remember)
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada_______________________________________________ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/ listinfo/pd-list
"[W]e have invented the technology to eliminate scarcity, but we are deliberately throwing it away to benefit those who profit from scarcity." -John Gilmore
PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
On Fri, 5 Jan 2007, Kyle Klipowicz wrote:
I wish that individual files would have their own separate help files quite often. Say, when getting help for ctrlin or midiin (or others of their ilk), it's quite annoying to new (and more seasoned) users to get detailed information on these objects.
While I agree that this particular helpfile could be somewhat more than just hands-on guess-what-this-is-for, I believe that breaking it down would remove the big picture: it would deemphasize the relationships, the patterns. Those classes are better explained as a group because half of them are opposite of the other half and each pair of opposites shares some behaviour with another pair. e.g. I can organise those in a grid like
[ctlin] [notein] [ctlout] [noteout]
And so, if I teach those, why would I want to teach each of them as if it lived in a bubble, when I could teach the rows and columns of that grid, the in-ness, the out-ness, the ctl-ness and the note-ness of those things?
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
On Jan 6, 2007, at 1:44 AM, Mathieu Bouchard wrote:
On Fri, 5 Jan 2007, Kyle Klipowicz wrote:
I wish that individual files would have their own separate help
files quite often. Say, when getting help for ctrlin or midiin
(or others of their ilk), it's quite annoying to new (and more
seasoned) users to get detailed information on these objects.While I agree that this particular helpfile could be somewhat more
than just hands-on guess-what-this-is-for, I believe that breaking
it down would remove the big picture: it would deemphasize the
relationships, the patterns. Those classes are better explained as
a group because half of them are opposite of the other half and
each pair of opposites shares some behaviour with another pair.
e.g. I can organise those in a grid like[ctlin] [notein] [ctlout] [noteout]
And so, if I teach those, why would I want to teach each of them as
if it lived in a bubble, when I could teach the rows and columns of
that grid, the in-ness, the out-ness, the ctl-ness and the note- ness of those things?
No one said anything about ignoring other objects. You should any
other object to make good examples, that's the important part. And
each help file should highlight the object in question and the
specifics of that object.
.hc
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
Man has survived hitherto because he was too ignorant to know how to
realize his wishes. Now that he can realize them, he must either
change them, or perish. -William Carlos Williams
On Sat, 6 Jan 2007, Hans-Christoph Steiner wrote:
On Jan 6, 2007, at 1:44 AM, Mathieu Bouchard wrote:
Those classes are better explained as a group because half of them are opposite of the other half and each pair of opposites shares some behaviour with another pair. e.g. I can organise those in a grid like [ctlin] [notein] [ctlout] [noteout]
No one said anything about ignoring other objects. You should any other object to make good examples, that's the important part. And each help file should highlight the object in question and the specifics of that object.
But none of those four classes in my example have anything really specific about them. Put in a different way, everything specific about one of them is found in another of the four classes. If you want to document individual inlets and individual outlets, you'll find what looks like an individual difference, but are we there to explain all inlets and outlets one by one, or are we there to explain how the data flows?
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
On Sat, 6 Jan 2007, Steffen wrote:
On 06/01/2007, at 15.41, Mathieu Bouchard wrote:
are we there to explain all inlets and outlets one by one, or are we there to explain how the data flows?
how about both (in the order you mention)?
What I'm trying to say is that if you describe what's flowing in the wire that connects the outlet to the inlet, then it's redundant to say what's coming out of the outlet and/or what's coming into the inlet.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
On Jan 6, 2007, at 12:56 PM, Mathieu Bouchard wrote:
On Sat, 6 Jan 2007, Steffen wrote:
On 06/01/2007, at 15.41, Mathieu Bouchard wrote:
are we there to explain all inlets and outlets one by one, or are
we there to explain how the data flows?how about both (in the order you mention)?
What I'm trying to say is that if you describe what's flowing in
the wire that connects the outlet to the inlet, then it's redundant
to say what's coming out of the outlet and/or what's coming into
the inlet.
Its easier to visually layout the info clearly when describing the
inlets (among other reasons), so that's how we've handled it. Plus
it makes for a good quick reference.
If you really want to get into the details of the decisions that were
made, I encourage you to check the archives, that works better than
my memory:
.hc
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
http://at.or.at/hans/
On Jan 6, 2007, at 10:11 AM, Steffen wrote:
On 06/01/2007, at 15.41, Mathieu Bouchard wrote:
are we there to explain all inlets and outlets one by one, or are
we there to explain how the data flows?how about both (in the order you mention)?
Yeah, both. We really should finalize that PDDP template, it would
make things clearer. So many things to do...
Here are the drafts:
http://puredata.org/dev/pddp/DraftReferenceDesigns
.hc
Access to computers should be unlimited and total. - the hacker ethic
On Fri, 5 Jan 2007, Hans-Christoph Steiner wrote:
The PDDP standard for this is to have every object have its own help file, then have a shared "all_about" patch for the common parts.
But how much is the PDDP "standard" grounded in actual practice, as opposed to plans of future practice? Then what's the incentive to take it for granted?
So, tell me, what's doc/pddp/operators-help.pd and doc/pddp/otherbinops-help.pd and how do they follow the PDDP standard. Then explain to me what's making the PDDP standard a standard.
Each object's help patch should have an example that is specific to that object. If there aren't different examples, then I don't see the point of having different objects...
But what if I come up with the same example, involving the N different objects, in N different help patches. Do I have to copy+paste it all over the place?
But how about answering the question that was in the mail that you replied to? That is:
How do I specify the name of the helpfile I want to have opened? I want to do like class_sethelpsymbol() but for abstractions instead of externals.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
On Jan 6, 2007, at 1:32 AM, Mathieu Bouchard wrote:
On Fri, 5 Jan 2007, Hans-Christoph Steiner wrote:
The PDDP standard for this is to have every object have its own
help file, then have a shared "all_about" patch for the common parts.But how much is the PDDP "standard" grounded in actual practice, as
opposed to plans of future practice? Then what's the incentive to
take it for granted?So, tell me, what's doc/pddp/operators-help.pd and doc/pddp/ otherbinops-help.pd and how do they follow the PDDP standard. Then
explain to me what's making the PDDP standard a standard.Each object's help patch should have an example that is specific
to that object. If there aren't different examples, then I don't
see the point of having different objects...But what if I come up with the same example, involving the N
different objects, in N different help patches. Do I have to copy +paste it all over the place?But how about answering the question that was in the mail that you
replied to? That is:How do I specify the name of the helpfile I want to have opened? I want to do like class_sethelpsymbol() but for abstractions
instead of externals.
Personally, I think that class_sethelpsymbol() should be deprecated
and removed, so I wouldn't advocate for the same thing for Pd
objects. I think it encourages kludges.
.hc
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
Man has survived hitherto because he was too ignorant to know how to
realize his wishes. Now that he can realize them, he must either
change them, or perish. -William Carlos Williams
On Sat, 6 Jan 2007, Hans-Christoph Steiner wrote:
Personally, I think that class_sethelpsymbol() should be deprecated and removed, so I wouldn't advocate for the same thing for Pd objects. I think it encourages kludges.
Man, I don't want to get that personal.
Now excuse me while I go find a way to encourage kludges.
And good luck with your PDDP Standard that you don't want to answer questions about.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada