|
As the baseline position, I'm with Rohan in not wanting to perturb the basic scsynth specification; co-opting control bus numbers should be a no-no, but good that we seem to have resolved that and defended poor old control bus 0. I've been reading back through the thread trying to work out your motivations to introduce this, and whilst I can see that you want some easy way to plug Synths together through audio inputs and outputs without using the audio bus system, I'm not sure how compatible this all is with the underlying scsynth architecture. Perhaps what you actually want is a psuedo-UGen, modules of class code to easily plug into new SynthDefs? Sure, maybe some hack to the control inputs of a synth can achieve the aim of plugging audio rate stuff around, but I'm still not convinced by any use case yet. Is there some clear client code that could demonstrate why this would be at all useful? Does it always lead to an implicit A2K? So I want to just provide a caution on A2K in the first place on signal processing terms. Checking the A2K source code I see a dangerous downsampler, since no low pass filtering is employed. Isn't A2K (just take first sample in block, decimate by factor of blocksize) particularly prone to aliasing? Perhaps a job for Erik's http://www.mega-nerd.com/SRC/? best, Nick On 19 Dec 2008, at 04:40, Josh Parmenter wrote: This already happens with UGens that only take a k-rate input but are fed an audio rate signal. So it isn't completely out of left field. |