(add your own requests and contributions!)
* Missing documentation.
- New interfaces to the Hid device.
- Especially the differences between the KBHit and the Hid way of dealing with the keyboard turn out to lead to questions.
- On the forum Spencer noted;
All ugens have a .op parameter, which specifies how they deal with multiple inputs. the default is for the ugen to just add multiple inputs, but specifying 3 for .op will cause the ugen to multiply its inputs together. Since this happens "below the hood" so to speak its a lot better CPU-wise than multiplying in ChucK, with the added benefit of being updated every sample. The manual only lists -1, 0 and 1 as options with he full range being being explained at the "Gain" ugen entry.
- The "this" keyword, similar to "me" except with regard to class-instances seems to be undocumented. Spencer explains here.
- Similarly: from some exchanges on the Forum around 14 Feb 2007: "there are a couple of references to "this" in the chuck manual. pages 31, 81. but no documentation of it's (or should i say this's) use."
Kassen replied: "I looked those up and you are right, but those references are a bit... erm.... thin (to say the least). It does make one wonder what "pure" does. The "pure" keyword gets mentioned on page 31 as well and that's the only reference to it. "const" is another mysterious word in that list." So in summary, we need some better explanations of "this", "new", "pure" and "const".
- Many of the examples referred to in the reference section as being in the /examples directory, (for example, osc.ck, pwm.ck, etc.) are no longer found there or in any subdirectories that I have been able to tell.
* Outdated info.
- From mailing list, original text by Tazumi and Spencer, dec8;
> i have got a question about sending strings with the osc class.. > ist this possible? > The manual says that the osc object has 2 member functions > (addInt / addFloat).. > so is there a way to send (or revieve) other data types?
It seems the manual is out of date in this regard, it is in fact possible to send strings in ChucK's OSC implementation. Just use an "s" for the type specifier and addString to supply the string. getString will retrieve the string on the listener end.
* Suggested clarifications
- Add new section on this page for manual/doc errata?
- p. 121 of ChucK manual 188.8.131.52: Flute instrument; should the parameters .startBowing and .stopBowing really be .startBlowing and .stopBlowing like they are for Clarinet? (previous page)
- Could somebody please go into what the word "new" means in ChucK, exactly? It's currently mentioned in the manual exactly once (in that sense). It creates a new instance of a object and it's somehow syntactically similar to "!" and that's about it as far as the manual is concerned.
- The section on getting MIDI input is reportedly hard to understand.
- "one window ChucK" doesn't work like that on Windows, only on Linux and OSX because the Windows command line refuses to give you your prompt back. The manual currently implies (on page 18 according to the file's numbering) that this will work on all systems which confuses new Win-based users. Why new users (including me a while ago) flock to a paragraph labeled as optional for hardcore veterans might be a good subject for a thesis on documentation writing...
Seems a little unfair to ding on readers who are attempting to make sense of documentation which is obviously in an early state.
"One window ChucK is only for the hardest of hardcore and not possible on a Windows command line." might do the trick though maybe Cygwin offers a solution?
This is more helpful. There is no problem with the Windows command line giving you a prompt back; it's only that the Command window doesn't have a concept of launching a process in the "background" (like Unix "&"). Maybe it's ignorant of me, but I can't really see why a ChucK listener can't be launched from a command line (e.g. chuck --loop) which will spawn off the VM/listener and then return to the prompt...
- The bottom of page 35 talks about indexing arrays "int-based" (as opposed to the associative way). Maybe a different wording would be more fortunate, considering that "int" is also a type of array itself?