Category Archives: Hardware

HowTo: Microkorg XL Sound Editor on Linux

Posted on by
2

Despite Wine bug #17608, you really can use Korg’s editor to adjust the deepest levels of your Microkorg XL on-the-fly, with instant playback results! Seems I’m not the only one to do this, in fact.

I did run into one problem: the MIDI ports on my AudioFire2 don’t show up on the ALSA MIDI tab, so the editor can’t see them. Wine seems to rely on ALSA MIDI devices, which means we need to provide a bridge between the native FireWire MIDI interface, on the MIDI tab, and the ALSA MIDI tab.

The solution: a2jmidid. This is, of course, only necessary if you’re using physical MIDI cables; a USB-MIDI device should show up on the right part of the Connections manager in QJackCtl. You may even be able to avoid these steps entirely if you can get the plain ol’ USB port right on the MK XL working; I haven’t tried that yet. I wanted to try out the AudioFire2′s MIDI dongle, which meant experimenting with JACK and ALSA.

But first, let’s get the Korg Sound Editor installed.

1. Download the latest version of the editor from Korg.
2. Unzip it, and run the installer in Wine:

$ unzip MkXL_Editor_100E.zip
$ wine microKORG\ XL\ Sound\ Editor/Setup_E.exe

3. Start your JACK server using QJackCtl.
4. Install a2jmidid, then launch it:

$ a2jmidid --export-hw

5. Open the Connections manager in QJackCtl, then switch to the MIDI tab. Connect the Midi through (capture) virtual device on the left side to the firewire_pcm device on the right side. Now connect the left side’s firewire_pcm to the Midi through (playback) device on the right side. This will let the Sound Editor communicate with your MK XL via Wine’s MIDI transport layer.
6. Now you can launch the Korg Sound Editor from your Program Menu:
Wine -> Programs -> KORG -> microKORG XL -> microKORG XL Sound Editor
7. In Sound Editor’s main window, go to options -> Preferences. Change both of the MIDI_IN/OUT dropdown boxes to Midi through Port-0. You’ll get a few warnings and popup dialogs about missing (and unnecessary) Windows-only USB-MIDI drivers, but as long as you have your cables physically plugged in correctly, you should now have working two-way communication with your MK and your computer. make sure you have the Knob Function Select dial on “Full Edit” if you want to be able to reprogram your synth or save presets to it.
8. To test your connection, double-click one of the patches on the “Program” Sound Editor screen. Once its window loads, click “Edit Synth” on TIMBRE 1. In the new window, click “Randomize” on the top left. Play a few notes. Click “Randomize” again, wait for the settings to be transmitted, then play s’more. Yay for realtime parameter changes!

I still have to delve into my Microkorg XL. Don’t know how to use it or synthesize new and awesome sounds, but at least I’ve got it working with Linux.

music made with gentoo: 20110530

Posted on by
3

Music:
20110530 by ioflow

Art:

This is a typical workflow when making music with only a monome and a computer, no piano. I use a mix of software and hardware controllers. Most of the former is native Linux, though there may also be a Windows Max/MSP application running in Wine, which I can control via MIDI or OSC. The audio generated is then sent to a variety of places for effects, processing, and recording.

This picture was originally inspired by a recent creative one-a-day by Jared Smyth, signalpath.

This drawing represents today’s audio sketch, which was an improvisation with polygome. I finally got polygome to connect with serialosc and griddle, a Linux-native OSC spanner/splitter/router application. My Gentoo Linux desktop looked like this while I was recording:

The monome was connected to serialosc, which converts the raw USB serial data into OSC messages, which are then passed to griddle. Griddle acts as an intermediary; it can combine multiple physical monomes into one unit, or it can split a single monome into two or more “virtual” devices. This would allow me to divide my 128 into two 64s, with each half being used for a completely different application.

Griddle exchanges OSC messages with polygome, a Max/MSP application running within Wine. Polygome doesn’t produce any sounds of its own, but sends MIDI output to a suitable source that does produce sound. In this case, fluidsynth. The audio from fluidsynth is sent to a software effects rack, and that processed audio is sent to an audio recorder and the system audio device‘s stereo output, so that I can monitor the mix.

The audio is tweaked in realtime by using a Korg NanoKontrol USB-MIDI device, which has some of the software effects rack parameters mapped to physical sliders. All the audio and MIDI input/output is tied together by QJackCtl. On the OSC/monome side, the input/output all goes through griddle, although for this recording session it was not strictly necessary, as I was running a single application on only one monome.

Config and process notes

I had to make a few config file changes to make serialosc, griddle, and polygome to cooperate. I also worked with griddle’s upstream to address a couple of bugs, which were solved within seconds. Collaborating on #monome is a good way to gain solutions and inspiration.

1. Start qjackctl, the synths, and effects.
2. Start griddle, serialosc, and Max/MSP in Wine, using the File -> Open dialog to select the polygome Max patch.

These are the configuration files to get all the software layers talking with each other. The ports change dynamically each time, except for serialosc.maxpat. Since serialosc and griddle will auto-negotiate new ports each time they’re run, the key thing is to make sure that the ports in serialosc.maxpat match the ports in griddle. Additionally, I had to specify the same application port in serialosc’s config. Normally, when serialosc and the Max patch are directly connected, you just have to make those ports match in your monome’s serialosc config and serialosc.maxpat

~/.config/serialosc/m128-000.conf: 

server {
  port = 17165
}
application {
  osc_prefix = "/monome"
  host = "127.0.0.1"
  port = 8000
}
device {
  rotation = 180
}

~/griddle.conf: 

[test]
port    = 49730
size    = 16, 8
offset  = 0, 0
# attached physical devices
m128-000 = 0,0

serialosc.maxpat: 

line 24> "text" : "loadmess set port 49730",
line 38> "text" : "port 49730",
line 78> "text" : "udpreceive 8000",
line 92> "text" : "udpsend localhost 49730",

polygome: Once running, click the “/sys/prefix /gome” button to send the application prefix to griddle, and then it’s possible to interact with polygome on the monome. Requires my special static version of serialosc.maxpat on github to work with serialosc, which has to be copied into the same folder as _polygome.maxpat.

Music made with Gentoo, and some modding

Posted on by
2

Tonight’s experiment, this time with mlr + the smyth rhodes samples from another track I created. Performed on a monome 128, in Gentoo Linux.


20110528 by ioflow

Instead of the Ubuntu laptop, I used my Gentoo desktop to sketch this out. It actually runs the Max/MSP patches (within Wine), such as mlr, better than Ubuntu. I don’t have much in the way of processing or FX software installed yet, so this is an extremely minimal arrangement; just a single Calf reverb effect and some fadeout postproduction in Ardour. I’m steadily writing ebuilds and adding them to my overlay.

mlr only supports audio files recorded at 44.1khz, and the ones I loaded were recorded at 96khz, which led to some interesting playback speeds; it cut playback by about half. It really brought out the transient sounds at the start and end of loops, which I used as percussive effect, playing the samples with kind of guitar-like strumming. I left in one loop at the original tempo, to add some high-end sound. It was a lot of fun — which is what experiments should be.

The picture is a screenshot of my working environment: mlr + JACK Timemachine + QJackCtl + JACKrack + monomeserial. Linux is amazing.

The audio from mlr (via WineASIO) is running to JACKrack, which contains a couple of FX, and the output from JACKrack is then run into the system audio device and simultaneously into JACK Timemachine, which is the big green button to the top right. Timemachine records the raw audio to a .wav file, which I can then process in Ardour.

I tweaked the amount of reverb in realtime with my hardware MIDI controller, a Korg NanoKontrol. I recently modded it, so here’s a picture of the finished project. It looks very nice, and feels even nicer. It has a matte, smooth, velvety finish now. It practically has a soft glow all by itself. Korg really should sell ‘em just like this.

Nanokontrol disassembly guide

0. Setup your workplace. Put some soft material down, such old towels. You’ll be putting some pressure on delicate electronic components, and you’ll be working with a lot of very fine dust: ABS plastic and blue paint. Use a very fine sandpaper grit for the finishing touches, if not for the whole project. I used 220-grit, which gave lovely results.

1. Get the knobs and faders off. Pull them straight up with just a little bit of pressure; they’re easy to remove.

2. Unscrew the screws. Flip the device over, and carefully peel off the rubber grip-pads. Those little round pads cover the screw holes. Set them aside on a clean, dust-free surface. You’ll need a fairly small Phillips screwdriver to remove the outer shell, and a much tinier Phillips for the 8 inner screws holding the inner shell to the circuitboard. There are 6 screws holding the outer shell together, and 8 more holding the inner shell to the circuitboard. That’s about 6 too many. Be careful with the inner screws! The heads are very soft, so too much torque or pressure will strip them.

3. Set aside the circuitboard and backplate; cover them with a towel. Once you start sanding, the dust will get everywhere. Now, start sanding! Remember, you pretty much only get one shot at this, since the screws are so flimsy that you likely won’t be able to take it apart once it’s reassembled. Pay particular attention to the cutouts for knobs and faders and buttons. These take the most attention, but be careful not to scrub too hard! The plastic is very soft, and you will open the holes too wide if you focus on one area too long.

The difference between a quality mod and a subpar one-off is the amount of time you’re willing to spend making sure that each and every last fleck of blue paint is removed, inside and out.

4. When you’re finished sanding, wash the outer shell and faceplate with plain water, to remove the paint and plastic dust. Thoroughly towel them off and set ‘em aside to air-dry before you reassemble the device.

5. Reassemble in reverse order, putting on the knobs and faders last. I left the paint strips on mine, but you’re free to remove those as well, or even give ‘em glow-in-the-dark or UV-reactive paint treatments. Enjoy your new awesome nanokontrol!

Music & NanoKontrol modding

Posted on by

Had a productive morning. Woke up at 8, then an hour later sat down to make some music with my monome. Finished in an hour, including preparation, performance, and postproduction. The results are on my SoundCloud.

Afterward, I picked up some 220-grit sandpaper, because I decided to mod my Korg NanoKontrol. I figured that it would look better without the retro 80s paintjob, so I disassembled it to get at the faceplate.

It’s coming along pretty well, so far. The tiniest screws in the circuitboard are troublesome; there are 8 of them, besides the bigger ones for the faceplate. The detailed sanding around the control cutouts is taking the most time; I’ve spent an hour so far, and I’m still not done.

The device is no longer so slippery to hold; it’s edging toward a nice matte finish, just a bit velvety. It’s lost the reflective gloss–which was a fingerprint magnet–but it still feels smooth, and I’m not done yet.

HowTo: RadeonHD 4550, Gallium3D, UT2004

Posted on by

Time for a quick status report on the latest git checkout of the FOSS xf86-video-ati driver for my RadeonHD 4550. It’s also a guide to getting the same free software stack working on your machine!

Open source drivers: then

I stopped using the open source Radeon driver some months ago, because I started playing Unreal Tournament 2004 again. At the time, the FOSS drivers were completely unusable. I had to lower the game’s resolution and detail to the point that my eyes hurt; the screen was a blurry, pixelated mess. That was back when the “classic” Mesa stack, which I was using, offered better performance than the Gallium3D code. I switched to the proprietary fglrx driver (Catalyst 10 and 11 series). Using this driver meant reinstalling the it for every kernel rebuild, giving up the flicker-KMS boot experience, viewing low-resolution consoles, and dealing with all the 2D lag in regular desktop use that the proprietary ATI driver is justly famous for.

Last year, the FOSS Radeon driver was good enough to run World of Goo and ioQuake engine-based games, but not much else. Sure, 2D desktop compositing performance was stellar, but there was no possibility of running more demanding OpenGL games like UT2004 or even Aquaria without significant stutter, lag, and low framerates. There was no real power management implemented, so my video card ran hotter all the time. There was also no hardware acceleration for video playback (DVDs, etc.) or Flash, though that’s probably still the case today.

Open source drivers: now

Everything has changed. The “classic” Mesa code has been obsoleted in favor of the Gallium3D stack, which offers superior performance. I can play Unreal Tournament 2004 with all detail settings maxed, at 1440×900 resolution, on an older RadeonHD 4550.

Before I could try UT2004 with the open drivers, it required preparing my system. Here’s how you can do it!

Switching to the open source drivers

For reference, my current working software versions:

(All git checkouts from May 13, 2011)
Mesa git: ac85ab066b7e3a7ee818849491b97a499038190b
libdrm git: ba11501bb9f5bd98110dfe1385b4501c0a9a643a
xf86-video-ati git: f83d58cf5b33686139067f8f898b8e566ba5c253
xorg-server: 1.9.5
kernel: 2.6.38.4

Assuming you already have the FOSS Radeon driver installed, you’ll need to update your git checkouts; emerge will do this for you. Git ebuilds are available in my overlay, and the X11 overlay. This is to get the latest code that hasn’t yet been released in official packages; there are several recent commits that have vastly improved 3D performance. Be sure to add required ~arch packages to /etc/portage/package.accept_keywords.

Configure the compile variables

Gallium3D is where all the hot driver action is these days for R600 cards, so make sure it’s in your compilation variables:

$ grep VIDEO_CARDS /etc/make.conf
VIDEO_CARDS="r600 fglrx"

Note: I left in fglrx, that way it’s still available as an option should you decide to switch back, and you won’t need to recompile anything to do so.

Make sure that you’ve got gallium enabled in your USE flags for media-libs/mesa, and that radeon is turned off. Why off? This code is the classic code for old devices; we don’t need it, since we’re only building for an R600 card. This saves you a considerable amount of compilation time.

$ grep mesa /etc/portage/package.use
media-libs/mesa -video_cards_radeon gallium gles

Compile and install the FOSS drivers

You’ll need to emerge mesa, xf86-video-ati, libdrm, and xorg-server. Once everything is installed, you’ll need to tell your system which driver stack it will be using.

Specify the open source stack

First, select the right OpenGL provider:

# eselect opengl list
Available OpenGL implementations:
  [1]   ati *
  [2]   xorg-x11
# eselect opengl set 2

Now that you’re using mesa, make sure to select the gallium options:

# eselect mesa list
64bit r600 (Radeon R600-R700, Evergreen, Northern Islands)
  [1]   classic
  [2]   gallium *
64bit sw (Software renderer)
  [1]   classic
  [2]   gallium *

Configuring kernel modules

If you haven’t already, you need reconfigure your kernel and add support for the new Direct Rendering Manager code to get hardware acceleration.

# cd /usr/src/linux
# make menuconfig
Device Drivers  --->
  Graphics support  --->
   Direct Rendering Manager --->
     ATI Radeon
  [*]     Enable modesetting on radeon by default

Save your kernel configuration, build, and install the kernel. Here’s my one-liner:

# make -j4 & make modules_install && make install

Next, make sure that only the radeon module is loaded at boot. Comment out the fglrx entry:

# nano -w /etc/modules.autoload.d/kernel-2.6

radeon
##fglrx

Note:I’m still using baselayout-1; baselayout-2/OpenRC users should look in /etc/conf.d/modules.

Blacklist the fglrx module so that it never loads:

# echo "fglrx" >> /etc/modprobe.d/blacklist.conf

Configure X11

If you use /etc/X11/xorg.conf (or /etc/X11/xorg.conf.d/), configure X to use the radeon driver:

# nano -w /etc/X11/xorg.conf
Section  "Device"
  Identifier "RadeonHD 4550"
  Driver "radeon"
EndSection
Section "dri"
  Mode 0666
EndSection

I don’t have any other optimizations in xorg.conf. No additional parameters or heat/power management, mostly because I can’t find what options still exist for those. Anyone know? Any additional tips on getting more performance and less power usage from X11?

That should be it! Now all you have to do is reboot into your new open source software stack, and start having some fun.

Performance notes

World of Goo: no change. It’s just as fast as ever. No hitches or slow framerates.
UT2004: Playable. No real complaints. A few things to be aware of, however . . .

I played a few maps, and noticed some moments of slowdown and lower frames. This mostly occurs on very large, detailed maps, or when the whole map is onscreen at once, such as in the Spectator view. Framerates are usually in the 40-60 FPS range, up to the cap at 140FPS. It all depends on how much is being drawn on the screen. More players, weapons, vehicles, monsters, effects, and action can add up to lower framerates.

Still, it was quite playable, never venturing below 30 FPS. Once I got into framerates in the 40s, there was some slight, noticeable stutter, but not enough to ruin my shots against AI monsters. Against lots of human players, you might need to lower the screen detail or resolution to deliver smooth framerates at all times.

Here’s a screenshot of a fairly busy map (about 20 simultaneous human players, plus dozens of monsters), with a crazy, GPU-crunching shimmery golden force field effect wall at the far end. Note the framerates displayed in the upper right corner.

UT2004 on Linux

UT2004 on Linux. Map: "The End"