Undocumented Features
What's the word on discussing and potentially documenting undocumented features? Occasionally I find it easier to just read the ChucK source than trying to find documentation for what I need, and I have noticed things that are undocumented. Their working state is questionable, but I have found at least one thing that is exceptionally convenient for me but remains unspoken of on the official documentation that appears to be stable: the Osc class. Internally it sits between UGen and the following classes on the inheritance tree: Phasor, SinOsc, TriOsc, SawOsc, PulseOsc, and SqrOsc. I find it useful for making collections of oscillators whose type I can change dynamically. I.e., in my current project, I have a two-dimensional array of Osc references that I can use to store a mixed collection of the aforementioned UGens. As an example, here's how I dynamically switch what base Osc object is being used, which would be much more verbose without the Osc class: fun void setPatch(string targetPatch, int column, int row) { if(!checkRange(column, row, "setPatch")) return; Osc s; // You can't use UGen here, because the UGen class has no freq property if(targetPatch == "SinOsc") { new SinOsc @=> s; } else if(targetPatch == "SqrOsc") { new SqrOsc @=> s; } else if(targetPatch == "SawOsc") { new SawOsc @=> s; } else if(targetPatch == "TriOsc") { new TriOsc @=> s; } else { cherr <= "Unrecognized targetPatch supplied in OscBank.setPatch:" <= targetPatch <= IO.newline(); } toneMap()[column][row] => s.freq; bank[column][row] =< gains[column][row]; s @=> bank[column][row] => gains[column][row]; } This seems to be a really general tool, since I'd wager that the supermajority of us go through ChucK 101 with little more than the SinOsc and Noise UGens. Where's the proper place to document my finding so that others can find it? Is there somewhere that this already happens? -Jordan
This seems to be a really general tool, since I'd wager that the supermajority of us go through ChucK 101 with little more than the SinOsc and Noise UGens. Where's the proper place to document my finding so that others can find it? Is there somewhere that this already happens?
Really nice find! I suppose the correct spot would be a inheritance tree that would be a part of the reference section of the manual? Such a section would have to be made, but it sounds very useful for the exact reasons you explain in your mail. Kas.
participants (2)
-
Jordan Orelli
-
Kassen