I built a performable looper prototype this past Sunday night. At this point, all it can do is start and stop two loops and a metronome. Rough around the edges is an understatement, though there are a few points of interest worth mentioning.

Rather than use Csound’s built-in tempo engine, I built one from a phasor. Players can trigger, retrigger and stop loops from the ascii keyboard. Triggering is also quantized to the beat, similar to how clips in Ableton Live are handled.

All in all, the whole thing came together in about two hours, plus another hour to tidy things up. Sure, there are some glaring flaws to the current design, but these things will improve with revision. For example, only two loops are supported, and they are hardwired into the engine. Samples and their mappings need greater levels of flexibility if this thing is going to be useful to anyone.

If you’re curious to try it out, download looper_prototype.csd. You will also need two samples from the OLPC sound library. The first is “110 Kool Skool II.wav” by BT, included in BT44.zip. The second is “BNGABetterArpeggio01.wav” by Flavio Gaete, included in FlavioGaete44.zip. Just drop these two samples into the same folder as the csd before running. You can replace these with your own loops, just make sure that you also update the values of the tempo loop macros, right above where the samples are loaded in the orchestra.

Here are the keys (lowercase only):

a – trigger loop a
z – stop loop a
s – trigger loop s
x – stop loop s
d – turn on metronome
c – turn off metronome

I’ll post a newer version once improvements to the design have been made.

Here’s a somewhat controversial hack that let’s you normalize a Csound composition during the rendering process, scaling the amplitudes using Csound’s 32-bit or 64-bit resolutions.

This hack requires two renders. The first time you render a composition, look for the overall amps value at the end of the output message. It will look something similar to this:

end of score.           overall amps:  0.64963

Next, you need to calculate the +3dB value above the overall amps value. Here is a function that does the trick, where x is overall amps:

f(x) = 10 ** (3.0 / 20.0) * x

Or if you want to skip most of the math involved:

f(x) = 1.4125375446227544 * x

Plug 0.64963 into x, and you get 0.91762676511328001. Set 0dbfs to this:

sr = 44100
kr = 4410
ksmps = 10
nchnls = 1
;0dbfs = 1.0
0dbfs = 0.91762676511328001  ; 3dB normalization

Render again. Done.

This is a Hack

Though I do love this technique, I highly recommend that you use it only for a few situations, and certainly advise that you don’t make a habit of it.

I like to use this when I’m finished with a composition, and I’m ready to make a master audio file. This allows me to squeeze out a tiny bit of extra sound quality by scaling the audio inside csound64’s internal 64-bit float resolution. Which in theory, will do a better job that if I did the same process to a rendered sample of a lower bit resolution.

This can also be a last ditch effort for fixing problems with a final project that is due in 15 minutes. You have some minor clipping, and no time to globally adjust all your amplitudes? This could save you in a pinch.

Warning!!

This only works with absolute amplitudes. If there are any relative values or opcodes in play, then this technique will fail. For example, these two lines of instrument code will not work:

a1 oscils p4 * 0dbfs, 440, 0  ; Scales the amplitude relative to 0dbfs
a2 diskin2 "foo.wav", 1       ; Scales the sample relative to 0dbfs

There are some other risks involved. If random elements exist in the composition, then the overall amps may vary between renders, which could lead to innaccurate normalization. I also highly suspect that the overall amps value at the end of the render is truncated, thus, it not pinpoint accurate — close enough for most situations.

Think if an electric guitar as if it were a Csound instrument, metaphorically speaking. Potential ways in which someone can interact with this guitar include: pick, fingers, ebow, power drill, slide, capo, etc. While the guitar is always a guitar, the output changes with the way a person interfaces with it. This concept is every bit as true for digital instruments as physical ones.

The original Splice and Stutter came with a single loop-based sample engine, aptly named SampleEngine. This engine is played with three interface instruments (Basic, Stutter and Random) each with its own unique musical behavior. Today’s example leaves SampleEngine exactly as is, and continues to demonstrate interface versatility with three new instruments: RandomPhrase, Swell and Flam.

The designs of these new instruments were influenced by the original Splice and Stutter score. After I had completed the demo, I noticed some gestures/phrases/effects that were translatable into instrument behaviors.

Download: splice_and_stutter_v2.csd. BT Sample Pack (13.2 MB)

RandomPhrase

If you look at the end of the score in the original splice_and_stutter.csd, you’ll see a 32 line long phrase using the Random instrument. With the exception of the start times, the p-fields for each line are identical.

i $Random 32.25 1 0.25 0.333 100

i $Random +     . .    .     .

...

i $Random +     . .    .     .

That is a pattern, and patterns are translatable into behaviors. RandomPhrase achieves this by generating multiple events of over an interval of time, specified in p-field 4, with events spaced evenly apart by the value in p-field 5.

i $RandomPhrase 32.25 1 32 1 0.25 0.2 100

In the new score, the original 32 lines of code are consolidated into a single call to RandomPhrase. This means less code to maintain, while giving the loop-based sampler a new behavior for me to play with.

Important note. RandomPhrase generates events for instrument Random, which generates events for instrument SampleEngine, which produces the sound. You can create new interfaces out of other interfaces.

Swell

Another pattern revealed itself with this gesture:

i $Stutter 7    1 0.25 0.5     100 12 [1 / 12]

i $Stutter 7.25 1 0.25 0.25    100 .  [1 / 12]

i $Stutter 7.5  1 0.25 0.125   100 .  [1 / 12]

i $Stutter 7.75 1 0.25 0.06125 100 .  [1 / 12]

Unlike the randomly generated notes from the previous example, p-field column 5 (amplitude) uses various values for each note event in this phrase. Upon closer inspection, these particular values themselves have a pattern. Each successive amplitude is halved. This p-field pattern, and others like it, can be translated into a behavioral instrument.

The Swell instrument lets users specify a multiplier to change the amplitude values for each successive note in p-field 6. What’s good for amplitude is good for other things, so I applied the same basic principle to the stutter window, expanding the usefulness of the instrument. A swell gesture looks like this in the new score:

i $Swell 7 1 1 0.5 0.5 0.25 12 100 [1 / 12] 1

Flam

In the original score code, I created a flam effect with two Basic events:

i $Basic 11    1 0.5 0.6 100 7

i $Basic 11.02 1 0.5 0.2 100 1

One could miss the intention of these two lines while reading the score. By creating an instrument that creates a flam, the score becomes easier to read. Also, a flam effect is musically interesting enough to justify having an instrument dedicated to it.

i $Flam 11 1 0.25 0.3 100 7 0.02 2 0

Let’s look again at the code presented on page 45 of The Technology of Computer Music:

INS 0 1 ;

OSC P5 P6 B2 F2 P30 ;

OUT B2 B1 ;

END ;

GEN 0 1 2 0 0 .999 50 .999 205 -.999 306 -.999 461 0 511 ;

NOT 0 1 .50 125 8.45 ;

NOT .75 1 .17 250 8.45 ;

NOT 1.00 1 .50 500 8.45 ;

NOT 1.75 1 .17 1000 8.93 ;

NOT 2.00 1 .95 2000 10.04 ;

NOT 3.00 1 .95 1000 8.45 ;

NOT 4.00 1 .50 500 8.93 ;

NOT 4.75 1 .17 500 8.93 ;

NOT 5.00 1 .50 700 8.93 ;

NOT 5.75 1 .17 1000 13.39 ;

NOT 6.00 1 1.95 2000 12.65 ;

TER 8.00 ;

The following list compares Music V mneumonics to their Csound opcode equivalents in the order in which they appear the previous example:

INS => instr

OSC => oscil

OUT => out

END => endin

GEN => f

NOT => i

TER => e

A Music V instrument definition begins with INS and and is terminated with END. This is nearly identical to Csound’s instr and endin. Music V does allow one capability that Csound lacks, as instrument defininitions in Music V have a parameter that lets users specify the time in which they come into being. Hopefully someday, Csound will include a more mature version of this feature, where users can dynamically create and destroy instruments in the middle of a score or performance. *crosses fingers*

Though OSC and oscil are similar, there are some noticeable differences in their implementations. In part 3, I mentioned that Csound supports control signals, and Music V does not. The oscil opcode is an example of a unit generator that can output both audio rate and control rate signals.

Both support a simple amplitude value, but diverge on frequency. Instead of a frequency paramenter, Music V has an increment parameter that determines the frequency of the unit generator. The increment parameter is used to specify the number of samples that are sequentially skipped in a stored function for each pass. The following equation is used to convert increment values to frequencies (Mathews, pg. 127):

frequency = sampling rate * increment / (function length in samples - 1)

The first note played in the example specifies an increment value of 8.45. Let’s do the math:

330.72407045009783 = 20000 * 8.45 / (512 - 1)

An increment value of 8.45 translates to roughly 330Hz.  Provided that the sampling rate is 20kHz and the table size is 512.

The problem with Music V’s method is that any changes made to the size of the stored function table or the sampling rate greatly affects the frequencies of the oscillators. The reason why I modified my copy of Music V is because the examples in the book were designed to render with a sampling rate of 20kHz, not 44.1kHz. Thus, frequencies were higher than they were supposed to be, and the LFOs were right out.

This is where Csound is much more user-friendly as users specify a frequency, and all the increment calculations are done automatically, making life a little easier for us Csounders.

Thanks for reading this first Csound Blog mini series. Hopefully you’ll stay tuned.  A lot of great topics are coming up, including coding techniques, composition, sound design, etc..