Monthly Archives for February 2013

Day 24: Fun-a-Day DC Style

I started this whole Fun-a-Day thing on account of my friends up in NYC, but apparently, there is a DC chapter as well. I’m told they had an event at Qualia Coffee today, which I sadly missed.

That’s fine because I stayed up really late last night working on my güiro patch, and I feel like things are finally coming together. I cleaned up my Csound code, and then set it up so I could trigger the güiro sound with the drum pads on my Electribe ER-1. I bought this drum machine over a decade ago, and it is so satisfying to breath new life into an old machine. What’s interesting is that the drum machine appears to only send information about velocity when you play the pads manually. I guess that makes sense, but it means that I need to read the MIDI in a different way in order to be able to program the güiro beats with the drum machine.

That’s fine because my real interest in using the drum machine was for its knobs, which would control the parameters of my drum sound. I can always program the actual beats in Csound, but I want live control over those parameters via physical knobs. I tried setting this up, but it turns out that the ER-1 uses NRPN MIDI signals, and while Csound has an opcode for producing NRPN’s, it doesn’t have one for receiving them.  I spent a good portion of yesterday evening mining the web for info on this and trying to get ctrl14 to read the NRPN as a 14-bit MIDI signal, which is apparently something entirely different.

Finally, at the end of the night, I discovered the midiin opcode, which reads MIDI events as raw data and lets the user decide how to interpret that data. I haven’t had a chance yet to implement this, but it will allow me to finally set up those knobs. If I get this working correctly, I could turn my ER-1 into a Latin drum machine with up to eight different drum sounds, each with completely unique parameters. I might just do this because I already have an FM conga patch that I wrote in Csound a while ago. If I do go that route, I’m going to make covers for the ER-1 that can be printed out and placed over the drum machine so that each knob is labelled appropriately. A pretty cool hack.

If nothing else, I’m learning a lot about MIDI from this project.

Day 23: Success.

I had a fun, productive meeting with the Maracuyistas today. There’s exciting things in the pipeline so stay tuned for more info on that!

In the meantime, I have solved my MIDI woes! This article was *very* helpful for straightening out the different MIDI systems in Linux. Basically, ALSA and JACK each have their own MIDI system, but the JACK one cannot communicate with hardware (only software.) There are two ways to combine the systems (raw and seq.) My USB Audio Interface wants me to use seq, which is fine because that’s the more sophisticated method of the two.

If you open the “Connect” window in qjackctl, it has three tabs: Audio, MIDI, and ALSA. The first one connects the actual digital audio signals so that you can pipe the audio from one program into another and so on. The other two tabs are actually both MIDI connections. The MIDI tab connects MIDI within the JACK system, and the ALSA tab connects MIDI within the ALSA system.

The program Patchage provides an alternative way of visualizing these connections. In that system, digital connections are represented in blue, ALSA MIDI connections in red, and JACK MIDI connections in green. The program a2jmidid can port between ALSA and JACK MIDI connections, but this can also be done through JACK’s midi-through, something not mentioned in the above article. I found this patchage tutorial very helpful.

After reading through these two threads:

  1. http://csound.1045644.n5.nabble.com/no-midi-input-td5714939.html
  2. http://www.linuxmusicians.com/viewtopic.php?f=47&t=7975

I discovered that the real-time MIDI support via JACK was not configured correctly on my computer (since I upgraded to Ubuntu Studio through the general Ubuntu distribution.) To fix that, I followed the instructions here, adding myself the the audio group and giving the audio group permissions to access the rtprio, nice, and memlock limits (whatever those are.)

That eliminated the errors I was getting before only to introduce new ones. It turns out that MIDI is even more complicated. There is also some sort of kernel-level virtual MIDI, and Csound can only communite with virtual MIDI ports. As this article suggests, you can enable these by runnings

sudo modprobe snd-virmidi

On my system, this adds four new “virtual” midi ports, which appear in the output of “amidi -l” as

IO hw:2,0 Virtual Raw MIDI (16 subdevices)
IO hw:2,1 Virtual Raw MIDI (16 subdevices)
IO hw:2,2 Virtual Raw MIDI (16 subdevices)
IO hw:2,3 Virtual Raw MIDI (16 subdevices)

Awesome. So now I run csound with the following options

-d --sched -+rtaudio=jack -o dac:system:playback_ -+rtmidi=alsa -Ma -b 256 -B 2048

and everything starts up as its supposed to without any errors. Finally, I go into Patchage and connect the MIDI from my USB Audio Interface (AudioBox 1818 VSL) to the first virtual raw midi port (Virtual Raw MIDI 2-3) and ¡wepa! I have working MIDI.

As you can see, it was no small feat getting this working, and gives me a better appreciation for why so few musicians use Linux. Why does everything have to be so goddamn complicated?!

Now that I know my way around MIDI, I’m going to spend the rest of my evening plugging everything the güiro patch I wrote. It will be run from drum machine as though it were a built-in drum sound, and I will be able to modify all the parameters of its sound live just by twisting knobs. A complete and total success.

Day 22: Baby steps for MIDI

I bought a MIDI cable today after I realized I could connect MIDI devices through my USB audio interface. I plugged by Korg Electribe ER-1 into the Audio Interface, fired up QMidiArp, enabled logging of MIDI events, and started turning knobs. I’m getting real-time feedback. The MIDI is definitely working! This is exciting because it means I can just program a rhythm in on my drum machine (a pleasant, tangible interface,) but have it modify the patch in Csound. Basically, my ER-1 will be able to control the güiro patch as though it were one of the built-in drum sounds.

That’s the good news; the bad news is that I cannot get Csound to recognize any alsa midi device and I spent a good long time messing with this. I’m feeling very frustrated so I’m giving up for today. Baby steps…

Day 20? Something like that…

I kinda fell off the Fun-a-Day bandwagon for the last 5 days, but I’m getting back into the swing of things. I had an idea today to use my DX7 or my Electribe ER-1 as an external MIDI controller for my güiro patch. Turns out that this is very commonplace, using a non-MIDI controller keyboard as a MIDI controller keyboard. I need to get a MIDI-to-USB cable though.

I also started cleaning up the güiro patch code. I commented what each thing does, and tomorrow I’m going to map it all out on paper and come up with appropriate names for the variables. Right now, it’s a mess. For example, I have two triangle waves that play analogous roles but one is called atri while the other is amod. These should be atri1 and atri2.

Also, I looked into setting a default value for a slider with ctrl7. I didn’t realize that the 7 refers to a 7-bit MIDI message (and not the 7th of several ctrl opcodes.) It turns out that you can set default values, but you have to use a different opcode: initc7.

Tomorrow, I’ll finish cleaning the code up, and set up the MIDI sliders.

Day 14: The Day of Looove

I’m running out the door to see Los Rakas so we’ll keep this short. Today, I took that Csound program I wrote yesterday and turned one of the sliders in the virtual MIDI keyboard into a pitch-bender. The code was simple:

knote ctrl7 1, 1, inote, inote*4

knote is a control variable that uses the ctrl7 opcode to get its value. The first 1 after ctrl7 indicates to use MIDI channel 1, and the second 1 indicates to use control knob/slider/etc number 1. The last two values indicate the minimum and maximum values in the range of the slider. So you can basically bend the note from its initial value of inote up to four times its original pitch (i.e. 2 octaves.) Here’s the full instrument code:


sr = 44100
kr = 4410
ksmps = 10
nchnls = 2

instr 1
iamp = p4
inote = p5
knote ctrl7 1, 1, inote, inote*4
a1 oscil iamp, knote, 1
outs a1, a1
endin

and the score looks like this

f0 20000
f1 0 4096 10 1 ; sine wave

i1 0 20 15000 440

Now, all the pieces are in place. I just need to set aside some time to clean up the güiro code, add the sliders, and figure out good min/max values for each of the sliders. I should also find a way to set the default slider value. I bet that’s an option with ctrl7.

Day 13: I can’t believe it’s already been 13 days!

If there’s one thing Fun-a-day gives me a good appreciation for it’s how quickly time passes. Can’t believe we’re almost halfway through the month and it just feels like last week that I was writing up that first post.

Today was a success. After reading these Realtime Csound on Linux: Tips and Tricks, and playing around with different settings, I was able to get an instrument working that played a very simple sine wave via the Virtual Midi Keyboard. In the end, I used these options in my csd file.

-d -+rtaudio=jack -o dac:system:playback_ -M0 -+rtmidi=virtual -b 256 -B 2048

The coolest part about MIDI in Csound is that you still have a score and as the score progresses, csound records your MIDI input and applies it to the the instrument. This means that I can have a musical score with the güiro beats programmed in already, and then use MIDI to control the timbre of the güiro in real-time by adjusting knobs. Since everything runs through JACK, I can direct the output of this “performance” to Ardour and record it.

Day 12: I <3 Csound

I completely forgot about Fun-a-Day yesterday so I’m making a quick update this morning and then I’ll have a followup tonight. Working with Csound is reminding me just how much I love this programming language. There is so much depth and yet you need very little code to do impressive things. Here’s some links I’m going to explore tonight:

Day 10: Brainstorming

I spent most of yesterday working on güiro patches so today’s post will be short and sweet. I’m pretty happy with the patch I wrote yesterday. It has all the right components, and I think all I need to do now is tweak the parameters a little. The metallic part at the beginning is too long and the scraping sound is too subtle. That means I need to turn up the LFO and decrease the decay on the triangle waves.

Eventually, I would like to have one patch whose parameters I could modify by twisting knobs on a MIDI device to shape the timbre of the güiro. For example, one knob might add more metallic clang by lengthening the sustain/decay of the triangle waves. Another knob might adjust pitch, raising/lowering the base cut-off frequency of the high-pass filter and altering the pitch of the triangle waves. The vco opcode allows you to modify the saw/ramp characteristics of the triangle wave, making it brighter or hollower. Another knob might affect this parameter, making the sound sharper or hollower.

The work-flow should go like this:

  1. Identify which parameters should be adjustable by the user.
  2. Write the Csound code that makes these parameters adjustable via MIDI.
  3. Play around with different knobs to determine good min/max values for each of the parameters. They should be set so that most values produce a güiro sound but the endpoints produce something more exotic.
  4. Play around with different knobs to determine the best default values.
  5. Write a simple proof-of-concept track where the parameters are adjusted as the track progresses, causing the güiro’s timbre to evolve and move.

Today, I did number 1 on this list. Number 2 will probably take me the rest of the week since I need to read up on MIDI in Csound (and since MIDI has already proven to be a problem on my computer.) I’ll do 3, 4, and 5 in the 2nd half of the month along with some alternative patches should time allow.

Knobs:

  • Metallic – modifies the sustain/decay of the triangle waves, thus affecting the amount of metallic clang at the beginning of the sound
  • Scrape – Raises/lowers the amplitude of the LFO, thus adjusting the amount of scraping noise. I should also consider allowing one to adjust how much LFO is applied to the triangle waves versus the white noise generator, and I may also want to have a knob that adjusts the frequency of the LFO so that the scrapes can be spaced closer/further apart. Maybe this should be 3 knobs, called scrape amplitude, scrape frequency, and scrape metallicness?
  • Swoosh – Raises/lowers the amplitude of the white noise generator, thus giving the güiro more/less of a shaker-style swoosh.
  • Pitch – Raises/lowers the cut-off frequency of the high-pass filter and the frequencies of the triangle waves, thus adjusting the pitch of the güiro. At low frequencies it will sound dull and at high frequencies it will sound bright and crisp.
  • ADSR (Attack/Decay/Sustain/Release) – Actually 4 knobs that adjust the envelope generator’s ADSR so that the güiro can have a faster attack, etc. I think I will probably not implement a decay knob since the güiro has more of an ASR sound.
  • Hollowness – Modifies the shape of the triangle waves to make the sounder sharper or hollower. This is an advanced knob that I may never implement.

I may also add a third triangle wave to make the instrument’s pitch less perceivable, and I need to figure out how to distinguish the up-strokes and down-strokes of the güiro. I think it has to do with the high-pass filter, which for up-strokes should maybe be a low-pass filter? I will put the up-strokes and down-strokes on separate tracks, and control their parameters with the same MIDI input.