Kane and I recently dropped $170 at JameCo on potentiometers, switches, diodes, project boards, and more in anticipation of several MuCo projects we have been planning. The main project now after some op-amp FAIL last night (the FAIL being Mimms’s op-amp. Yes, there is a free version on the nets. No, we will not help you torrent it illegally) is a classic 3×3 matrix mixer which we intend to use a la David Tudor to make feedback music of the most splendiforous nature. As some of you may have noticed, I have been slightly obsessed with feedback of late, and for good reason: feedback, like Frosted Flakes, is better than good, its great. It’s great to make, great to listen to, great to cover up the drunk, sleeping neighbor’s DVD menu music that runs for hours and hours after he’s passed out on the couch.
I plan to post a little “Fun with Feedback” post this weekend (maybe tomorrow), but I will jump the gun and get to results before I do. In anticipation of the analogue matrix mixer, I decided to spit in the eye of convention and model an analog (make an analog of…) device digitally first because I wanted to see what my results with the analog device might be.
This was an interesting experiment because it highlighted the reality that, while creating digital analogs of analog equipment may be useful on a basic, conceptual level, it breaks down completely when it comes to the actual implementation/realization of the object. This may seem obvious to some of you (congratulations), but one wouldn’t suspect this with the tradition of modelling analog equipment in electronic music studios the world over. Not to mention all of the digital synthesis software that models even its appearance. (Yes, Reason, I’m looking at you… with disdain.) I’ll make a long story short and say that approximately 2 minutes after I sat down with idea the matrix mixer in my head to start coding it up, I was conceptually far enough away from the analog instrument that looking at my notes one might not even guess it was supposed to be a simple 3×3 summing mixer. This is partly because of the nature of programming itself, and partly because of the idiosyncrasies of any programming language. If one were to mock up the 3×3 in Csound, SuperCollider, and ChucK, it would become very clear very quickly that one cannot think the same way about the same object when coding in different languages. I now digest. (yes, digest.)
After some headbanging and with some help from Kane and HJH (on Nabble) the Waz Matrix Mixer V.1 was realized last night. The SC3 code is below so you can see how it is constructed. The mixer is simple: it routes 3 input sources (in this case, either the built-in microphone or a sine oscillator) to 3 outputs each. At the outputs is some processing, a delay line, distortion, etc. The output from the processing can then be routed back into any of the inputs including itself, thus the feedback.
In the following picture, the blue knobs represent the 3×3 matrix. Each row routes its respective input to outs 1, 2, and 3 individually. The red knobs control the input volume, and the yellow knobs control the amount of outs 1, 2, and 3 that are fed back into the chain.
As promised, here is the code (provided Scribd ever finishes processing it…)
Here is a recording with the mic as the input source. I’m not actually doing anything with the mic, I’m just letting it hum and collect room noise and the output from the speaker which is right next to it in the laptop. The delay line’s delay time parameter is being dynamically changed using the mouse position (x axis) which results in pitch-shifting. This is responsible for the “glitching.” Additionally, I am using the mouse position y axis to control the decay time (in seconds.) When the decay time is over 3, the processing synths begin a sometimes irreversible pattern of self destruction.
Here is a recording of the sine oscillator inputs. There are three sine tones around 440, 1000, and 1400 Hz respectively. The rest of the processing is as described in the example above.