The Workings of FR-08's Sound System

by Tammo Hinrichs aka kb of Farbrausch Consumer Consulting

Back to articles page

Part 1 : The concept

Back in the summer of 2000, I was asked by Chaos / Ex-Sanity (who looks somewhat similar to the fabolous Powa of Elitegroup, but that's a completely different story) if I wanted to contribute the musical part to, as he called it, "the best 64k intro of all times". After I asked him to see that intro, he said that there wasn't anything finished until then, but that Fiver2 and him would deliver something in November which would definitely convince me.

And so they did. Damned. Every year I just want to take a rest from all those scene activities and every year the same story: "Let's win The Party". I'll NEVER escape this.

But so what, I should stop pretending that I'd have something called "life" and, well, it's fun and I had some ideas slumbering in my brain and waiting to be tried out anyway. So let's start.

1.1: A solution that doesn't suck?

But start with WHAT? I mean, I never was a good chip tune composer, I always took the memory I wanted or needed, and in the younger past, I only composed using "real" music equipment and all that stuff. And finally, I was really addicted to vocals :)

So, it HAS to be possible somehow to put a sound track into the 16K compressed executable size that Chaos granted me.. that leaves me as many of those things i'd learned loving as possible.

But how? Let's have a look at the solutions which existed before:

If you really think about it, tracked music sucks anyway. Face it: The whole format of modules, the way the patterns are displayed, organized in memory and played, was designed just for one single reason: Paula. MODs were made to have an easy way (as in "easy for the coder and the CPU", not "easy for the musician") to make the Amiga's sound chip (called Paula) play some samples, and that was it. And sadly, all other programs followed that paradigm, even though the MOD format itself was rendered obsolete by the first occurence of better Amiga CPUs or even software mixers. And to make it worse, all newer and well-known tracker programs carry TONS of overhead to make them at least a bit compatible to the original SoundTracker. And IMHO, for no convincing reason.
Additionally, we're living in the year 2001. CPUs are somewhat faster now than back then, music programs have evolved, there's a plethora of cool programs like Buzz or plugins for whatever format... and I just can't imagine why the heck anyone would consider a handful of mono samples without any effects or modulations enough for making good music. In terms of sound quality, every M***x Music Maker kiddie can just laugh about trackers' capabilities... and he would be right.

Ok, let's conclude: Every Existing Solution Sucks.

But what to do now? I want a flexible, good sounding sound system, an intuitive approach to composing, state-of-the-art sound quality (and vocals :) ... AND it has to fit into like 16K together will all music data. That sounds quite impossible, doesn't it?

1.2: Innovation through established ideas

Not at all.

Let's dig out one of the oldest standards for computer aided music there is: MIDI. When I'm talking about MIDI, I'm talking about the original "Music Instruments Digital Interface" standard which includes the definitions for a serial interface (standard RS232 asynchronous protocol, 32500 bits/sec, one start- and one stop-bit, no parity, no handshaking, using TTL voltages and this notorious 5-pin DIN plug with those even more notorious decoupling circuits) and the definitions for a simple protocol cabable of transferrin musical events such as "key pressed", "key released" or "modulation wheel turned a bit up". I'm also talking about the SMF file format (standard midi files, those .mid things) which contains nothing more than a time-stamped "log" of all events belonging to a song.

What I'm NOT talking about is the "General MIDI" standard (and all its derivates) which defines various standard sound banks and is what most people think of when they hear the word MIDI. That's a nice toy for distributing bad cover versions of charts songs over the net or for old DOS games or whatever. As mentioned above, this would sound, well, cheap.

"So... today's CPUs are quite fast. Also, today's the age of TnL 3D cards, so the CPU really doesn't have to do much in a demo. I've got all the time in the world."

(to which Chaos replied something in the lines of "if my intro drops to the second frame because of your synth, you'll die", but who cares)

Well, then... how about coding a complete realtime synthesis system which simply processes MIDI events, hooking it to a .mid file player and there you go? Ok, it will (and in fact DOES) suck up a lot of CPU time, but there are many advantages:

Maybe some of you will now complain that this way, you can't play samples anymore. But adding sample playback support to a softsynth is like 20 lines of ASM code or 5 lines of C++ if your concept is good. So maybe it's more coding work, but not really something I'd call a problem.

Ok, for the next chapter, you'll need a bit of knowledge about the MIDI protocol and maybe the .mid file format, so I'll leave this as a homework before you continue reading.

Back to articles page