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.