Wow and double wow
OK, this week I was able to go to an open house at Southwestern College in Chula Vista (outside San Diego, Calif.) and get a quick tour of the amazing recording studio that has been recently finished there. It’s a resource for their courses in recording engineering technology. I believe I heard that between $5 and$6 million was spent on it.
You can see pictures, panoramic views and see equipment lists here: http://xserve.swccd.edu/ras/Welcome.html
I am really envious of the students who get to work in this facility, and the musicians who’ve been able to record there. The professor, Jay Henry, who designed it from the ground up, also knows his stuff to an amazing degree. Check it out…
More Csound progress…
OK, lately (finding myself with a little extra spare time) I plunged back into Csound. In particular, I was working with some files I gathered over the years; some from the thonk processor, a few recorded with a tiny MP3 player on a city bus, and other random field and noise recordings. Nothing was really exciting me sonically, so I thought I’d delve back into the (extensive) granular synthesis and resynthesis tools available in Csound.
(Aside: Each time I do this I feel like I’m learning it from the ground up. Lesson: you definitely need to use it regularly to stay current!)
So I went and ran the various granular synthesis demo programs and listened to them to try to figure out if that kind of processing would allow me to get the sounds I think I’m interested in. There are several opcodes you can use to process either mathematical data or audio samples with granulation.
These are: grain, grain2 and grain3 (the older ones); granule (somewhat newer); and partikkel and partikkelsync (the newest, as far as I know.)
The problem is that, as with fractals, the parameters of the computation make a huge difference in the result. The only way this could be dealt with in the Old Days was to change the parameter, run it again, listen, change parameters again, etc. This is obviously terribly time consuming and inefficient.
[…still being worked on 25 Mar 2010…]
In going through old files and reprints, I came across a great article by Art Hunkins.