STUDENT# GRD3 10588567 A- 13204543 B 13207260 A- 13387832 A- 13430586 B 14001319 A- 34400888 A- 50798366 A 51965999 A 52657129 A 53745528 A 58932355 B 62512045 B 63484038 A- 67871978 A- 69581920 B 75720447 B+ 87185276 A 95245856 A 95386369 C 10588567: Faders only send integer values. You need to set the fader ranges, then do some math to put their output in the range that's appropriate for each particular usage. 13204543: Since you're adding direct and delayed versions of the sound, you should probably scale them by 0.5 to avoid clipping. The variable delay idea on the right channel is good; can you think of a way to make it more versatile (able to create a variety of similar effects)? 13207260: What is the intended function of the "expr f1*f2" object? 13387832: Good. Could add some sort of global controls to make it more "performable" and versatile? (E.g., some algorithms by which to change several parameters by moving a single controller?) 13430586: Channel 2 outlet of cd~ should be connected to second *~? No need to bang the "5" into reson~ repeatedly with the metro; once will do (or type in as arguments). The random object does not take min and max arguments; see help file. It would be preferable to window the output of the tapout~ objects with a five-second amplitude envelope, to fade out and back in just at the moment when the delay time is changed. (E.g., the metro could trigger a "1 50 1 4900 0 50" message to a line~ to a *~ to window the output of the tapout~.) The "volume control" slider only sends out integer values. Need to scale those values into a more usable range. 14001319: Bug in message ordering with 1500 message. Should be to right of both random objects. Output of slider should go to a * object, not a *~ object. 34400888: How to turn off metro? More automation of parameters? 50798366: Good. Could add features to make it more generalized and versatile? 51965999: Good. Could add features and controls to make it more generalized and versatile? How to turn off the metro? 52657129: Interesting. Could add some sort of global controls to make it more "performable" and versatile? (E.g., some algorithm by which to change all center frequencies or all gains by moving a single controller?) 53745528: Good. Could add some ways to initialize values, and to give "performable" control to parameters? 58932355: The groove~ plus three delays idea is too similar to another person's idea, and is not well implemented because all delay times are the same and invariable. The "1000" input to line should be in the second inlet, and should be to the right of the random object. The gain controls (*~) under the sfplay~ are not adjustable because the controls go in the wrong inlets, and there are no controls going in the right inlets. The phasor~ could use a variable frequency control. 62512045: Could add some controls or features to make it more dynamic, more "performable"? 63484038: Good. It would be preferable to window the output of the "tapout~ 300" object with a one-second amplitude envelope, to fade out and back in just at the moment when the delay time is changed. (E.g., the metro could trigger a "1 50 1 900 0 50" message to a line~ to a *~ to window the output of the tapout~.) 67871978: Good ideas. In delay patch, you should scale down the amplitude when adding two songs together, to avoid clipping. In chorusing patch, the patch cord of the second set of chorusing controls should go to the _right_ inlet of tapout~. In filter patch, some gain controls would help (over feedback amount, for example), to control distortion. The "gain~" object is only useful as a filter control here in the range of about 0-15. 69581920: Good working patch. Try to imagine an interesting modification you could do, and then try to implement that. 75720447: You need to have a value for the right operand of +~ in order to offset the modulating cycle~ object's value into the all-positive range. Also, you might want to scale the delayed output amplitude and feedback amplitude separately? 87185276: Very good. Check out the loadbang and/or preset objects for initializing values in a patch. Although your method works fine, in this case it might be easier just to play the sound repeatedly and change the volume of it each time it is iterated. You could simultaneously change the balance of direct and reverberated sound, to enhance the distance cueing. Good job of setting a goal, finding a solution, and implementing it. 95245856: Good. Some ability to vary delay times dynamically might be a good feature. 95386369: Output of filtergraph should go to _second_ inlet of biquad~. Argument to sfrecord~ is number of channels, not duration. (The "record" message to this object can have a duration argument, though.) Your use of function and line~ is incorrect. Check out Tutorial 7 for an example of how function works.