The Null Device

One of the things I enjoy doing is creating electronic music, for which I use a Macintosh laptop, some music software and various plugins. For the past few years, the software which I used has been Apple's Logic Express, to which I switched from Cubase VST when moving from MacOS 9 to OSX. As Logic didn't come with a drum machine program back then, I found myself buying Linplug's RMIV drum machine, which I have over the years used extensively.

RMIV is an excellent and comprehensive drum machine, which contains both analogue-style drum synthesisers and sample playing capabilities, as well as filters and effects. However, it has one downside; when you import sounds into it, it has the annoying tendency of saving those in its own proprietary format (rather than using a standard format such as, say, AIFF or WAV, both of which are good enough for other software including Apple's own samplers).

Recently I have started using Ableton Live, and have found it very impressive. While Live will happily load all my AudioUnit plugins, it also contains its own drum sample player, Drum Rack, which integrates more tightly with it. Drum Rack allows you to drag your favourite samples to various pads and play them. The hitch is that the samples must be in a standard format; if most of your drum samples are in RMIV's .D4T format, then you have a problem. Guess where most of my samples were?

Anyway, not being one to give up easily, I took it upon myself to examine the D4T format, and come up with a way of converting my samples to an open format. Luckily, I had some samples sitting around in both formats; after examining them with hexdump(1) and a Python interpreter, I soon determined that D4T is a fairly simple format, consisting of a short header and the samples in 32-bit float format.

The header turned out to be a bit more work; there were what looked like magic numbers in it, as well as some values roughly proportional to the file size, though bizarrely unrelated to actual sizes. After creating a few oddly-sized AIFF files, importing them into RMIV and examining the imported versions, I determined that RMIV's format used a bizarre way of encoding integers: it would encode them in binary-coded centimal. Which is to say, as a series of bytes, each containing a value from 1 to 99, representing a pair of decimal digits. Why they settled on this peculiar and inefficient encoding, I can only guess; it seems too feeble to be an attempt to thwart reverse engineering.

Anyway, the point of this anecdote is that I have now written a Python script which converts from RMIV's .D4T sample files to AIFF files. (One could change it fairly trivially to make WAV files, though that's left as an exercise to the reader.) The script, named "dermiv", is here.

¶ audio code computer music hacks mac python 2

My latest gift to the world's collection of marginally useful software: x64spriterip, a quick and dirty Python script which pulls sprite images out of Commodore 64 emulator memory dumps and writes them to PGM files. Just in case you ever felt like grabbing some graphics from your favourite childhood computer game for a chat-room avatar or T-shirt logo or somesuch but couldn't be arsed writing the software to do it yourself.

¶ code commodore 64 python 0

Two former WW2 codebreakers from Bletchley Park have turned their attention to a coded message on a garden monument in Staffordshire. The 18th-century inscription, on a garden monument, reads "D OUOSVAVV M". Oliver and Sheila Lawn have examined 48 hypotheses about the code, with the two leading categories being those connected to the Knights Templar/Freemasonry and the Holy Grail, pointing right into Holy Blood Holy Grail/Da Vinci Code territory. Other hypotheses involved UFOs, Nostradamus, Turkish maritime maps and occultism. Then again, it could have just been a dedication from the estate owner to his late wife. (via bOING bOING)

¶ bletchley park code cryptography mystery 6

My latest contribution to the corpus of GPLed code: jfifextract, a quick-and-dirty POSIX command-line program which goes through a file/disk volume (of arbitrary size; it uses mmap(2)), finds spans that look like JPEG files and writes them to a directory. This was not a dry academic exercise, mind you, but was necessitated by a dodgy memory card that somehow "misplaced" a directory full of photos somewhere between Sydney and Byron Bay.

¶ code data recovery jfif jpeg 0