I've been working with realtime Csound as a side project for a while, now. I decided to write up a short list of some of the tips and tricks I've discovered.

1. JACK is your friend

The options I used in the .csd files below were:


-d \
-+rtaudio=jack -o dac:system:playback_ \
-+rtmidi=alsa -M hw:1,0,1 \
-b 256 -B 512


These are the meanings for the settings, along with a bit of an explanation:

• -d -- Turn off displays. Useful during the time the instrument is being designed, but otherwise inconvenient.
• -+rtaudio=jack -- The settings I use for the JACK server are:
  -R -dalsa -dhw:0 -r44100 -p256 -n2
• -o dac:system:playback_ -- This was a gotcha when I upgraded to Hardy Heron . . . the name for the default playback is now under 'system:' instead of 'alsa_pcm:'
• -+rtmidi=alsa -- According to the posted directions, Csound doesn't automatically connect to MIDI ports; you have to use aconnect or a similar utility. But yet . . .
• -M hw:1,0,1 -- . . . with this flag, I can get Csound to directly read the raw MIDI input from my keyboard! (Proves it doesn't hurt to try something out, I guess.)
• -b 256 -B 512 -- Compatible settings to match the JACK server and dial up about 22 msec of latency.

2. GUIs are not your friends

My old computer runs about like Grandpa Walton on a day to day basis. However, it can run all of the Csound examples below, in real time, without a fuss.

The same is not true of my laptop. Even though it has a faster CPU, it choked on the vco2 examples (depending on how hard I played).

Why? Simple. The laptop has a huge screen. The GUI (KDE) spends a lot of time updating the screen, beaming in tool tips, antialiasing, etc.

Proof:

I shut down the GUI by logging out, then pulling down the menu in the lower right corner of the KDM manager and selecting "Console login". I was then returned to my old friend, the command line. This time, when I started JACK and any of the examples below, I couldn't get an xrun no matter how hard I played.

3. Velocity sensitivity is your friend

I tried to put a bit of velocity sensitivity in each of the models, below. Usually I went for a subtle effect. Actually, that seems to be the best kind -- something that makes the keyboard feel more 'real', but doesn't intrude into the soundscape with unnecessary flash.

4. Playing fast is not your friend

Notes with very long decay times (for example, the pad variations below) don't mix well with fast playing. Every synth, even a magic one like Csound, has a limit on the amount of realtime polyphony. It's simply not realistic to set up 16 voices to play on each keypress, with 5 seconds of decay for each voice, and then expect no xruns when you play "Giant Steps." [ Maybe in 10 years, but not now ;-) ]

5. Being precise is your friend, except when you're in a hurry.

When I compiled my own version of Csound, I chose double precision. I now see I need to custom compile another, alternative version of Csound, probably under /opt. This new version will have floats instead of doubles. That way, if I have a later instrument that keeps getting xruns, I can drop down in precision from /usr/local/bin/csound (doubles) to /opt/bin/csound (floats).

More on this later.

The Instruments

OK. The instruments below are simple, but they prove some points. One, they work. Two, they involve velocitization. Three, they sound smooth and cool (really the most important consideration).

For each of the types oscils, vco2sqr, and vco2tri, I've given three derivatives: p, k, and o. The 'p' variant feels like a pad -- a slow swell and long fall; the 'k' version has the traditional attack-decay profile of a keyboard instrument (piano, harpsichord); and the 'o' version is, of course, my favorite, the organ sound: easy on, easy off.

You will probably have to modify the '-M' setting to read your own particular set of hardware. Enjoy!