what is the process for suggesting improvements for the manual?
I haven't found anything that "officially" describes how to suggest changes to the manual. I've spotted a few things that I think should be fixed, or at least discussed. At least one of them is an actual error, while others are suggestions for how certain sections might be improved. Having said that, I would like to thank everyone who contributed to the manual. It looks very useful, and seems to be off to a great start. andy
Hi Andy,
The best thing to do is probably to fix the problems by editing the FLOSS
version of the manual yourself (you'll need to get an account at FLOSS
manuals).
Each chapter has a discussion page too, which could be used to ask/suggest
things, though you'd probably get a better response by asking the list
directly.
http://en.flossmanuals.net/bin/view/ChucK/WebHome
On Sat, Jan 9, 2010 at 7:17 PM, Andrew Turley
I haven't found anything that "officially" describes how to suggest changes to the manual. I've spotted a few things that I think should be fixed, or at least discussed. At least one of them is an actual error, while others are suggestions for how certain sections might be improved.
Having said that, I would like to thank everyone who contributed to the manual. It looks very useful, and seems to be off to a great start.
andy _______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users
Hi Tomasz: I enthusiastically second Andy's thanks to everyone who contributed to the manual, and to you for helping focus those efforts. But Andy makes a good point. For example, I'm not ready to become an editor. But I have specific comments[*] that might be useful the next time someone takes a pass over a chapter in the manual. Right now, my comments reside only in my head -- it would be good to have a place to present them for consideration in future edits. - Rob [*] Did you know that most unit generators don't describe the effect of chucking to their inputs? On 9 Jan 2010, at 10:23, Tomasz Kaye's brain wrote:
Hi Andy,
The best thing to do is probably to fix the problems by editing the FLOSS version of the manual yourself (you'll need to get an account at FLOSS manuals).
Each chapter has a discussion page too, which could be used to ask/ suggest things, though you'd probably get a better response by asking the list directly.
http://en.flossmanuals.net/bin/view/ChucK/WebHome
On Sat, Jan 9, 2010 at 7:17 PM, Andrew Turley
wrote: I haven't found anything that "officially" describes how to suggest changes to the manual. I've spotted a few things that I think should be fixed, or at least discussed. At least one of them is an actual error, while others are suggestions for how certain sections might be improved. Having said that, I would like to thank everyone who contributed to the manual. It looks very useful, and seems to be off to a great start.
andy _______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users
_______________________________________________ chuck-users mailing list chuck-users@lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/chuck-users
Rob; [*] Did you know that most unit generators don't describe the effect of
chucking to their inputs?
Wow, yes. That has been badly under-documented. As I see it now the best solution may be to just add a "input" field to all UGen descriptions. This will be "nothing" for most and a clear explanation in the case of filters, the basic osc's, Gain and a few others. In most cases it should be clear already, I can't imagine anyone living in much doubt about what the input of a reverb might do, but let's document it all anyway because there are cases where the *lack* of a input may be potentially confusing (StIffKarp, maybe) and those that don't do much without one (Envelope, for example, at least unless Perry's proposal is taken). It's a important UGen property and hence it needs to be documented, I agree. While we are at it we might as well note whether such in and outputs are mono or stereo. More generally; until we have a better system I don't see why these things couldn't or shouldn't be discussed on the list. If something is unclear to one person it will likely be puzzling to others as well, and it's not like anyone can tell your to "RTFM" :-). Thanks, Kas.
participants (4)
-
Andrew Turley
-
Kassen
-
Robert Poor
-
Tomasz Kaye's brain