Posted to youtube by greymedallia
“alto saxophone, guitar, csound”
The 7th issue of the Csound Journal was posted back in October, and I’m finally able to properly pimp it out to the world. Here is the list of articles pressent in this edition:
About a month ago, peiman posted a question to the Csound Mailing list about the possiblity “to batch process several audio-files with the same csound code.” Prior to this, I had never considered using Csound in this manner.
After some discussion on the list about how to do this, I presented a simple solution using the command-line. This bash call was then refined by sand-6.
I continued to work on this, as there were still a few unresolved issues. For example, designing Csound instruments that would process mono or stereo files automatically, and being able to set parameters from the command-line. I wrote ShellVerb v0.1 to demonstrate a way to build these abilities into command-line instruments. Though I wasn’t completely happy with my approach.
I revisted ShellVerb yesterday, and came up with ShellVerb v0.2. This version, in theory, works identically to v0.1 as far as the user is concerned. However, I made some changes internally that I hope are a bit more clear to those wishing to analyze the file so they can write their own Csound based command-line audio tools.
It turns out that not only can Csound be used as a batch processor, but it also makes for a damn fine one. Csound is chock full of filters, envelopes, digital siginal processors, spectral processors, etc. From these synthesizer/dsp modules, one can design very complex effects units that would be impractical to implement in most other products out in the wild. Since the original post at the mailing list, I’ve heavily incorporated Csound command-line processors into some of the projects I’m currently working on, with stellar results.
Download:
Building Csound
I haven’t forgotten about this place. I’ve just been really wicked busy. I’m going to do my best to make up for it starting right now.
I compiled Csound from source for the first time yesterday, for OS X. The experience wasn’t nearly as bad as I predicted it to be, as things went fairly smoothly. I did have to go google fishing for a few answers that weren’t explained in the build instructions. Though I attribute this more to my lack of understanding of SCons than anything else.
I need start doing my own builds from now on because I’m at a point where I can really use a 64-bit version of Csound (higher audio quality), and there is no prebuilt 64-bit package for my OS of choice. As of right now, my build works in a limited capacity, as I have a few issues to work out. For example, I’ve lost the ability to render in realtime. No biggie. It’s just a matter of time until I get everything working like clockwork.
Exciting stuff, I know.
In the previous blog, “Modular Instruments“, I presented an instrument design model that takes advantage of Csound’s modular nature by breaking the common instrument structure apart into three elements: Synth Engine, Memory and Interface. (SEMI)
In todays blog, I create a new synth named MonoSynth based on the original SEMI Simple synth by replacing the zak memory with a memory core based on the chn opcodes, extending functionality of the engine, introducing modulation parameters, and by incorporating a method that links instances of instruments into an audio chain from within the score.
Topics:
More at The Csound Blog. For more information about Csound, please visit cSounds.com.
When designing a virtual instrument in csound, the easiest approach is to create a single self-contained instr. Within this instr, any number of opcodes can be arranged in a near-infinite number of combinations. Each instance of the instr manages its own local memory space/variables/signals. Users customize the interface of the instr by utilizing p-fields.
With this fundamental model of instrument design, it is already apparent that Csound excels in terms of modularity. However, there are many other approaches that expand this concept even further.
Topics:
More at The Csound Blog. For more information about Csound, please visit cSounds.com.
I want to share with you a promising new site called Csound for Newbies.
“The purpose of this site is to help the feckless, the despondent, the hopeless and the overwhelmed musician, programmer, and/or composer who wants to learn about the Csound audio and music software system.”
I have no clue as to who runs this site. Though it appears we share the common goal of helping those who wish to learn more about the language. Csound is cursed with an initially steep learning curve, and it’s great to see a blog dedicated to addressing this issue.
“The Acoustic, the Digital and the Body: A Survey on Musical Instruments”
“In the autumn of 2006 we conducted a phenomenological, qualitative survey on people’s relationship with their acoustic and digitial instruments. This is part of an ongoing research.”
The survey is still open if you wish to participate.
via HectorC on the Csound Mailing list.
After matrixsynth.com picked up “My Sine Oscillator Experiment,” doktor future started a discussion about different ways of emulating analog oscillators in digital. Adam S mentioned that he thought the Plan B sine looked like a piecewise quadratic to him and provided the following function:
y=
-(4/pi^2)[x – (pi/2)]^2+1, x from 0 to pi
(4/pi^2)[x-(3pi/2)]^2-1, x from pi to 2pi
After having checked it out in grapher.app myself, and confirmed it did look similar to the Plan B sine, I implemented this as a wave table in Csound. See piecewise.csd.
Piecewise + Plan B Model 15
In this image, I have superimposed Adam’s recommended piecewise function over the Plan B’s Model 15 sine wave. As you can see, their contours are not quite identical, though very, very similar.
After listening to both waves side-by-side, the harmonic distortion in the piecewise sine example is a tad louder, and the frequencies are just slightly off. At least to my ears. However, I consider it to be a wonderful approximation of the Model 15.
Oh, the Irony
Peter Grenader, the principle designer at Plan B, has this written in his bio:
“In 2001 , Peter returned to analog after a 22 year hiatus because he tired of trying to force digital instruments to behave in like manner.”
I’m finding this whole discussion a bit humorous as the three of us are doing exactly this, trying to force digital instruments to sound like analog. In this case, Mr. Grenader’s analog oscillator.
Over the weekend, I recorded/generated four sine waves of different synthesizer modules and compared the results. Each of the four oscillators are tuned to approximately to 440Hz, close enough to get a sense of each wave shape.
This is a very casual observation of contour and contour only, so please do not read too much into my findings. Here are the results:
Csound Digital Oscillator
This first graph shows a digital sine wave generated within the computer music language Csound. This is what I used as my test reference. Being that this is a purely mathematical construct, I figured this would be the perfect wave to compare against its analog counterparts.
Doepfer A-110 Standard VCO
Upon casual observation, you may notice that the sine isn’t the most accurate in the world. In fact, you might go as far to say this isn’t a sine wave at all. One noticable feature of this oscillator is that little glitch you see at 90ยบ. This is consistent among every cycle at the stated frequency. I have two of these modules, and there were no significant differences when compared to each other.
Now it might sound like I’m completely down on this module. The truth is, I’m actually quite happy with this dirtiness of this unit, as it adds character. It is sometimes the imperfections that make something great.
Plan B Model 15
This unit has the smoothest contour of the three analog examples. Though the shape doesn’t adhere completely to the perfectly generated Csound test reference, it certainly gets close. The peak and the dip seem to be a bit rounder, almost as if they are slightly compressed.
Cwejman D-LFO
Now, I must say that it probably isn’t fair that I’m comparing a device designed specifically for low frequencies. With that being said, the contour fared noticeably better than the Doepfer. You might notice that the peak and the dip are both a little on the sharp side. The D-LFO comes with two oscillators, both of which I tested. I found both to be consistent with one another.
All Examples Compared
For fun, I thought it would be nice to superimpose each example over one another so we can better observe how much variation can exist between sine wave oscillators.
Other Variables in the Equation
Since I recorded the three analog signals, there were at least two extra variables that may have introduced distortion to the resulting wave shapes. The first would be the recording device, an Apogee Ensemble with the soft limit feature set to off. The second is the cable. I used the same cable for all the recordings. I always patched directly from the sine wave outputs to the Ensemble input.
I did go the extra step and recorded the Csound sine wave with the Ensemble and cable. I found there were no significant differences, in terms of contour, between the original generated wave and the recorded version.
My Methods
Last, I want to share the methods I used to collect and present the data. I recorded the three analog signals with the Apogee Ensemble, and with the software Peak. I took screen captures of peak, and then processed them in Photoshop. In Photoshop, I removed the dotted zero line, and replaced it with a solid line. I also resized each image so the waves would have matching periods. Though I compressed the width of each waveform, the contours of the waves were not affected.
And like I said, this experiment is just the casual observations of one guy, and completely non-scientific.