Hello all,
As you may be aware, I've been working on new reference files for PD. I've run into a 'snag' however and I'd like some advice.
The 'snag':
It's my personal opinion that detailed and specific documentation is always best. It's also my opinion that it's impossible to provide "too much" information about anything. Hence, it's also my opinion that every object in PD should have its own documentation. I'd like to build new documents for the MATH objects in PD but:
The binary operators, when right-clicked and "Help" is selected from the sub-menu, open a file called "operators.pd" or "otherbinops.pd". Similar problems also exist with objects like [dbtorms] and [mtof]; those files all open a file called "acoustics.pd".
I would like to build a help document for [+] and [==] for example, but those object names may not be good file names. ==.pd ?? I think that operating systems may not like those file names.
So the questions I have are these:
Any and all comments are welcome and greatly appreciated.
Regards, Dave Sabine
Hello Dave,
It would seem to me that things like ==, <=, >= != && || should all be on one page, to have documentation for all of them would be overly redundant. Once you understand how to use one then you understand how to use them all. this would aldo go for +, -, /, *.
BUT! I do think it would be good to have examples for what you could use all these objects for, which would not fit in one page.
So I guess I'm undecided on the issue, but there a couple pro/cons.
Good work. Ben
On Mon, 8 Jul 2002, David Sabine wrote:
Hello all,
As you may be aware, I've been working on new reference files for PD. I've run into a 'snag' however and I'd like some advice.
The 'snag':
It's my personal opinion that detailed and specific documentation is always best. It's also my opinion that it's impossible to provide "too much" information about anything. Hence, it's also my opinion that every object in PD should have its own documentation. I'd like to build new documents for the MATH objects in PD but:
The binary operators, when right-clicked and "Help" is selected from the sub-menu, open a file called "operators.pd" or "otherbinops.pd". Similar problems also exist with objects like [dbtorms] and [mtof]; those files all open a file called "acoustics.pd".
I would like to build a help document for [+] and [==] for example, but those object names may not be good file names. ==.pd ?? I think that operating systems may not like those file names.
So the questions I have are these:
- Do you all agree that each object in PD should have its own documentation?
- If so, then what changes need to be made to PD source code to open the appropriate help documents in the reference folder?
- Is it possible to build a subroutine in PD's source code which will:
- search first for a document in the reference folder which corresponds to the object name
- search for a document called "plus.pd" for the [+] object instead of a document called "+.pd"
- search for a document called "operators.pd" only if a 'dedicated' help document does not exist in the folder (and for backwards compatibility for PD users who haven't downloaded my help documents.
Any and all comments are welcome and greatly appreciated.
Regards, Dave Sabine
It would seem to me that things like ==, <=, >= != && || should all be on one page, to have documentation for all of them would be overly redundant. Once you understand how to use one then you understand how to use them all. this would aldo go for +, -, /, *.
BUT! I do think it would be good to have examples for what you could use all these objects for, which would not fit in one page.
actually this points to a very simple solution: revise the grouped operators help (requires no change to pd source), and subpatch other help (examples, finer points, etc.) inside. the help files for max do this frequently for 'more information', and i think it works well.
-j
David Sabine dave@davesabine.com wrote:
Hello all,
As you may be aware, I've been working on new reference files for PD. I've run into a 'snag' however and I'd like some advice.
Me too: I can't open your webpage.
I keep getting this error:
Microsoft OLE DB Provider for ODBC Drivers error '80040e21'
Multiple-step OLE DB operation generated errors. Check each OLE DB status value, if available. No work was done.
//global.asa, line 194
mik
Me too, can't open website that is? I'm sure it's an internet explorer problem!
--- mik mprims@skynet.be wrote: > David Sabine dave@davesabine.com wrote:
Hello all,
As you may be aware, I've been working on new
reference files for PD. I've run into a 'snag' however and I'd like some advice.
Me too: I can't open your webpage.
I keep getting this error:
Microsoft OLE DB Provider for ODBC Drivers error '80040e21'
Multiple-step OLE DB operation generated errors. Check each OLE DB status value, if available. No work was done.
//global.asa, line 194
mik
Do You Yahoo!? Everything you'll ever need on one web page from News and Sport to Email and Music Charts http://uk.my.yahoo.com
Meanwhile I have managed to open it with Opera. It didn't work with Galeon (Mozilla based).
mik
Rory Walsh rorytheroar@yahoo.com wrote:
Me too, can't open website that is? I'm sure it's an internet explorer problem!
--- mik mprims@skynet.be wrote: > David Sabine dave@davesabine.com wrote:
Hello all,
As you may be aware, I've been working on new
reference files for PD. I've run into a 'snag' however and I'd like some advice.
Me too: I can't open your webpage.
I keep getting this error:
Microsoft OLE DB Provider for ODBC Drivers error '80040e21'
Multiple-step OLE DB operation generated errors. Check each OLE DB status value, if available. No work was done.
//global.asa, line 194
mik
Do You Yahoo!? Everything you'll ever need on one web page from News and Sport to Email and Music Charts http://uk.my.yahoo.com
Firstly: 'tis grand that there's lots of work going into doco for PD.
There was a post on the jmax list recently that got me thinking. It was requesting automatic instantiation of parameter ui objects for an object - to short cut the process of plonking a new object in, checking the doco for its inputs, hacking together a quick rat's nest of its possible inputs and then continuing. I find myself doing this quite often, particularly when getting to know how an object works... and testing its operating ranges. It's only really an issue for objects that have/require lots of paramters... but there seem to be quite a few of those. Anyway, the problem reminded me of some help patches I've seen for nato (in max)....
Many pd doco (help files) present little sections of useful connections to illustrate the working of the relevant object. But why not have the object with all (or almost all) of its useful inputs connected to relevant controls in the help file, along with inlets and outlets to the help patch? Then instead of plonking a new object into your patch, you can insert the help file abstraction into your graph and then open it to manipulate the controls? Someone did some help files for nato which work this way. Very handy.
As Dave is doing such a thorough job of documenting objects I thought I'd throw in this idea as a suggestion for discussion.
I'm working on a release of some GEM externals and I think I'll try to follow this approach with those.
Daniel
Hi, Daniel Heckenberg hat gesagt: // Daniel Heckenberg wrote:
Many pd doco (help files) present little sections of useful connections to illustrate the working of the relevant object. But why not have the object with all (or almost all) of its useful inputs connected to relevant controls in the help file, along with inlets and outlets to the help patch? Then instead of plonking a new object into your patch, you can insert the help file abstraction into your graph and then open it to manipulate the controls? Someone did some help files for nato which work this way. Very handy.
The recently introduced graph on parent feature provides an IMO very nice solution to this. With GOP, you can build higher level objects that come with their GUI included. Three examples of this are included im my "angriff" drum patch at footils.org, the most simple one therein is [easydac~] which is a stereo dac~ object having a volume control slider (0-1) and a dsp-on/off switch.
Maybe we could start collecting such abstractions somewhere, but I don't think the helpfiles are the right place, they should focus on explaining the objects.
Frank Barknecht _ ______footils.org__
Hi,
I agree. There's a tree called "abstractions" in the pd cvs just for this purpose.
Juha
is [easydac~] which is a stereo dac~ object having a volume control slider (0-1) and a dsp-on/off switch.
Maybe we could start collecting such abstractions somewhere, but I don't think the helpfiles are the right place, they should focus on explaining the objects.
Hi, Juha Vehviläinen hat gesagt: // Juha Vehviläinen wrote:
I agree. There's a tree called "abstractions" in the pd cvs just for this purpose.
Oh, I didn't see that. As abstractions are just textfiles, they can be managed very well in CVS. How are the rights on this directory rsp. it's subdirs?
Frank Barknecht _ ______footils.org__
up to now everyone has every right. chaos rules ....
Guenter
On Tue, 23 Jul 2002, Frank Barknecht wrote:
Hi, Juha Vehvil�inen hat gesagt: // Juha Vehvil�inen wrote:
I agree. There's a tree called "abstractions" in the pd cvs just for this purpose.
Oh, I didn't see that. As abstractions are just textfiles, they can be managed very well in CVS. How are the rights on this directory rsp. it's subdirs?
ciao,
Frank Barknecht _ ______footils.org__
How about Daniels "example" abstraction just dropped inside the help patch? would not take any space or make things more confusing, but you can still copy and paste it into another patch) This is along the lines of the "more information" subpatch idea someone already mentioned.
Ben
On Tue, 23 Jul 2002, Frank Barknecht wrote:
Hi, Daniel Heckenberg hat gesagt: // Daniel Heckenberg wrote:
Many pd doco (help files) present little sections of useful connections to illustrate the working of the relevant object. But why not have the object with all (or almost all) of its useful inputs connected to relevant controls in the help file, along with inlets and outlets to the help patch? Then instead of plonking a new object into your patch, you can insert the help file abstraction into your graph and then open it to manipulate the controls? Someone did some help files for nato which work this way. Very handy.
The recently introduced graph on parent feature provides an IMO very nice solution to this. With GOP, you can build higher level objects that come with their GUI included. Three examples of this are included im my "angriff" drum patch at footils.org, the most simple one therein is [easydac~] which is a stereo dac~ object having a volume control slider (0-1) and a dsp-on/off switch.
Maybe we could start collecting such abstractions somewhere, but I don't think the helpfiles are the right place, they should focus on explaining the objects.
ciao,
Frank Barknecht _ ______footils.org__
The GOP feature looks great for making nicely modular components which include their UI.
However, isn't that a little different from providing a UI for explanation and demonstration purposes? In the one case you've packaged something up ready to use (e.g. the drum synth) and in the other you're trying to pull it apart and explain its ranges and functions? GOP stuff seems more appropriate for a usable UI for a higher-level abstraction and the help file approach is more about providing an interactive help page for an object that you may want to use in the context of the patch you're in the process of building - but probably won't end up using when you're finished building. (Because you'll make a nice GOP UI for your patch/abstraction)
Given that most PD help patches are done in the style of patches, it seems like a good idea to (when appropriate) make them a fully usable patch that can be:
to explore and accelerate things a bit.
?
Daniel
-----Original Message----- From: Ben Bogart - FMPM/F1999 [mailto:bbogart@acs.ryerson.ca] Sent: Tuesday, 23 July 2002 11:15 PM To: Frank Barknecht Cc: pd-list@iem.kug.ac.at Subject: Re: [PD] help files
How about Daniels "example" abstraction just dropped inside the help patch? would not take any space or make things more confusing, but you can still copy and paste it into another patch) This is along the lines of the "more information" subpatch idea someone already mentioned.
Ben
On Tue, 23 Jul 2002, Frank Barknecht wrote:
Hi, Daniel Heckenberg hat gesagt: // Daniel Heckenberg wrote:
Many pd doco (help files) present little sections of useful connections to illustrate the working of the relevant object. But why not have the object with all (or almost all) of its useful inputs connected to relevant controls in the help file, along with inlets and outlets to the help patch? Then instead of plonking a new object into your patch, you can insert the help file abstraction into your graph and then open it to manipulate the controls? Someone did some help files for nato which work this way. Very handy.
The recently introduced graph on parent feature provides an IMO very nice solution to this. With GOP, you can build higher level objects that come with their GUI included. Three examples of this are included im my "angriff" drum patch at footils.org, the most simple one therein is [easydac~] which is a stereo dac~ object having a volume control slider (0-1) and a dsp-on/off switch.
Maybe we could start collecting such abstractions somewhere, but I don't think the helpfiles are the right place, they should focus on explaining the objects.
ciao,
Frank Barknecht _ ______footils.org__
B. Bogart