Vessel
Did your virus scanner flag a download from our site? Click here to let us explain why!

Articles

The Workings of FR-08's Sound System - Part 1

by KB / Farbrausch

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:

  • Normal tracked music using MXMPlay/W or MiniFMOD or whatever:
    Well, to put it short: NO. Samples take up memory, and even those chippy, noisy crap samples I'd have to use would take too much. Apart from that, that's just how all of those 64k intros sound. There are enough musicians capable of doing nice tunes with such low resources, but most 64k intro soundtracks wouldn't survive long in "the real world".
  • Using modules with pre-calced samples from a softsynth ("the Stash way"):
    Nice. But still not what I wanted... You have to keep a software synthesizer AND a module player in the executable and there's no thing like "usability"... I respect Probe and the others for the great results the got, but I as a musician would rather quit the scene than compose a demo score typing hex bytes into the softsynth, re-compiling it, generating the samples, swithing to the tracker, loading the samples again, finding out that they don't REALLY fit... and so on. This solution may work, but really kills the whole work flow and the creativity.
    Additionally, I tried that before one year ago, and apart from the sad fact that the intro that we've been planning then was never even half finished, I did the music for the Mekka&Symposium 2000 invitation intro using that method and found out that it sucked.
  • And well, there are always FM synths and General Midi wavetable chips on today's sound cards. But as all they can do is "sound cheesy and cheap", this solution is really none. And first of all, you can't be sure that the song will sound the same on all computers.

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:

  • A .mid file player is MUCH smaller than an XM player... just read the file, wait until the next timestamp and send some commands to the synth... no effect processing, nothing.
  • Sound quality wise, realtime synthesis is much better than precalculated samples... Lines will sound more "natural" (as with analog equipment, no two sounds sound the same) and we can do really long filter sweeps and modulations without having to sacrifice several Megabytes of memory and precious seconds of precalc time for those sounds.
  • If the synth processes MIDI commands anyway, well, why not simply hook a small GUI for editing sounds to it and connect it to the MIDI sequencing program of your choice? That way, you can compose the whole song in Cubase (or Logic or Cakewalk or zTracker or Modix or whatever you prefer) and any sound change is just two mouse clicks (or one twist of a knob on the MIDI controller board next to you :) away and happens immediately, instead of "change, render, load, try, doesn't fit, change, render ...".
  • One nice side-effect is that the musical data in .mid files is stored in a quite more senseful way than tracker patterns (which were stored for easy access with a M68000 CPU, and that never really changed), and is generally smaller (in fact, that was not enough for me, but more about that later)

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.