With all the recent tinkering with audio devices and sound routines, I stumbled across various resources, old and new. One such resource was this article on OS/2 Museum, about the Gravis UltraSound. (And small world, this site is by Michal Necasek, who is on the OpenWatcom team, the C/C++ compiler I use for my 16-bit DOS projects). More specifically, the ‘flamewar’ between Rich Heimlich and the rest of the newsgroup, regarding the quality of the UltraSound patches, and general usability in games.
Now, as a long-time demoscener and Amiga guy, it probably doesn’t surprise you that I myself was an early adopter of the GUS, and it has always had a special place in my heart. So I decided to browse through that flamewar, for a trip down memory lane. I can understand both sides of the argument.
In the blue corner…
The GUS was not designed to be a perfect clone of a prior standard, and build on that, unlike most other sound cards. Eg, the original Sound Blaster was basically an AdLib with a joystick port and a DMA-driven DAC for digital audio added. Later Sound Blasters and clones would in turn build on 100% AdLib/Sound Blaster compatibility. Likewise, the Roland MT-32 set a standard. Roland Sound Canvas set another standard (General MIDI), and also included an MT-32 compatibility mode (which wasn’t quite 100% though). Most other MIDI devices would also try to be compatible with Sound Canvas/General MIDI, and sometimes even MT-32.
The GUS was different. Being a RAM-based wavetable synthesizer, it most closely resembles the Amiga’s Paula chip. Which is something completely alien to PCs. You upload samples, which you can then play at any pitch and volume, anywhere in the stereo image (panning). While there was a brave attempt at a software layer to make the thing compatible with Sound Blaster (SBOS), the nature of the hardware didn’t lend itself very well to simulating the Yamaha OPL2 FM chip. So the results weren’t that great.
In theory it would lend itself quite well to MIDI, and there was also an emulator available to support Roland MT-32 and Sound Canvas (Mega-Em). However, for a complete General MIDI patch set, you needed quite a lot of RAM, and that was the bottleneck here. Early cards only had 256kB. Later cards had 512kB and could be upgraded to a maximum of 1 MB. Even 1 MB is still quite cramped for a high-quality General MIDI patch set. Top quality ROM-based wavetable synthesizers would have around 4 MB of ROM to store the patches.
Since the card was rather new and not that well-known, there weren’t that many games that supported the card directly, so you often had to rely on these less-than-great emulators. Even when games did use the card natively, the results weren’t always that great. And that’s what I want to focus on in this blog, but more on that later.
I never used SBOS myself, so I suppose my perspective on the GUS is slightly different anyway. My first soundcard was a Sound Blaster Pro 2, and when I got a GUS some years later (being a C64/Amiga guy, the SB Pro never impressed me much. The music sounded bland and the card was very noisy), I just left the SB Pro in my system, so I had the best of both worlds: Full AdLib/SB compatibility, and GUS support (or MT-32/Sound Canvas emulation) when required.
In the red corner…
People who owned and loved the UltraSound, knew what the card was capable of, if you played to its strengths, rather than its weaknesses (as in the emulators).
Gravis included their own MIDI player, where you could configure the player to use specially tweaked patch sets for each song. The card could really shine there. For example, they included a solo piano piece, where the entire RAM could be used for a single high-quality piano patch:
Another demonstration they included was this one:
That works well for individual songs, because you know what instruments are and aren’t used. But for generic software like games, you have to support all instruments, so you have to cram all GM instruments into the available RAM.
And being so similar to the Amiga’s Paula, the GUS was quickly adopted by demosceners, who had just recently started to focus on the PC, and brought the Amiga’s ProTracker music to the PC. Initially just by software-mixing multiple channels and outputting on PC speaker, Covox, Sound Blaster or similar single-channel devices. So when the GUS came out, everything seemed to fall into place: This card was made to play modules. Each module contains only the samples it needs, so you make maximum use of the RAM on the card. The chip would perform all mixing in hardware, so there was very little CPU overhead for playing music, and the resulting quality was excellent.
On the Amiga, every game used tracked music. So that would be a great solution for the GUS on the PC as well, right? Well, apparently not, because in practice very few games included tracked music on PC. And of the few games that did, many of them were ported from the Amiga, and used the 4-channel 8-bit music from the Amiga as-is. That didn’t really give the GUS much of a chance to shine. It couldn’t show off its 16-bit quality or its ability to mix up to 32 channels in hardware. Mixing just 4 channels was not such a heavy load on the CPU at the time, so hardware mixing wasn’t that much of an advantage in this specific case.
Yamaha’s FM synthesis
As you may know, the Sound Blaster and AdLib cards used a Yamaha FM synthesizer chip. Originally they used the OPL2, later generations (starting with Sound Blaster Pro 2 and AdLib Gold), used the more advanced OPL3. Now, Yamaha is a big name in the synthesizer world. And their FM synthesis was hugely popular in the 80s, especially with their revolutionary DX7 synthesizer, which you can hear in many hits from that era.
But I just said that I thought the Sound Blaster Pro 2 sounded bland. What happened here? Well, my guess is that MIDI happened. The above flamewar with Rich Heimlich seems to revolve a lot around the capability of the devices to play MIDI data. Rich Heimlich was doing QA for game developers at the time, and apparently game developers thought MIDI was very important.
Yamaha’s chips, much like the GUS, weren’t that well-suited for MIDI. For different reasons however, although, some are related. That is, if you want to play MIDI data, you need to program the proper instruments into the FM synthesizer. If you just use generic instrument patches, your music will sound… generic.
Also, you are not exploiting the fact that it is in fact an FM synthesizer, and you can modify all the operators in realtime, doing cool filter sweeps and other special effects that make old synthesizers so cool.
So what is it that made MIDI popular? Let’s define MIDI first, because MIDI seems to mean different things to different people.
I think we have to distinguish between three different ‘forms’ of MIDI:
- MIDI as in the physical interface to connect musical devices
- MIDI as in the file format to store and replay music
- MIDI as in General MIDI
The first is not really relevant here. Early MIDI solutions on PC were actually a MIDI interface. For example, the MT-32 and Sound Canvas that were mentioned earlier were actually ‘sound modules’, which is basically a synthesizer without the keyboard. So the only way to get sound out of it is to send it MIDI data. Which you could do from any MIDI source, such as a MIDI keyboard, or a PC with a MIDI interface. The Roland MPU-401 was an early MIDI interface for PC, consisting of an ISA card and a breakout box with MIDI connections. The combination of MPU-401 + MT-32 became an early ‘standard’ in PC audio.
However, Roland later released the LAPC-I, which was essentially an MPU-401 and MT-32 integrated on an ISA card. So you no longer had any physical MIDI connection between the PC and the sound module. Various later sound cards would also offer MPU-401-compatibility, and redirect the MIDI data to their onboard synthesizer (like the GUS with its MegaEm emulation, or the Sound Blaster 16 with WaveBlaster option, or the AWE32). I can also mention the IBM Music Feature Card, which was a similar concept to the LAPC-I, except that its MIDI interface was not compatible with the MPU-401, and it contained a Yamaha FB-01 sound module instead of an MT-32.
So for PCs, the physical MIDI interface is not relevant. The MPU-401 hardware became a de-facto standard ‘API’ for sending MIDI data to a sound module. Whether or not that is actually implemented with a physical MIDI interface makes no difference for PC software.
Part of the MIDI standard is also a way to store the MIDI data that is normally sent over the interface to a file, officially called ‘Standard MIDI file’ or sometimes SMF. It is basically a real-time log of MIDI data coming in from an interface: a sequence of MIDI data events, with delta timestamps of very high accuracy (up to microsecond resolution). We mostly know them as ‘.MID’ files. These are also not that relevant to PC games. That is, they may be used in the early stages of composing the music, but most developers will at some point convert the MIDI data to a custom format that is more suited to realtime playback during a game on various hardware.
Now this is the part that affects sound cards, and the GUS in particular. Initially, MIDI was nothing more than the first two points: an interface and a file format. So where is the problem? Well, MIDI merely describes a number of ‘events’, such as note on/off, vibrato, etc. So MIDI events tell a sound module what to play, but nothing more. For example, you can send an event to select ‘program 3’, and then to play a C#4 at velocity 87.
The problem is… what is ‘program 3’? That’s not described by the MIDI events. Different sound modules could have entirely different types of instruments mapped to the same programs. And even if you map to the same instruments, the ‘piano’ of one sound module will sound different to the other, and one module may support things like aftertouch, while another module does not, so the expression is not the same.
In the PC-world, the MT-32 became the de-facto standard, because it just happened to be the first commonly available/supported MIDI device. So games assumed that you connected an MT-32, and so they knew what instruments mapped to which programs. One reason why the IBM Music Feature Card failed was because its FB-01 was very different from the MT-32, and the music had to be tweaked specifically for the unit to even sound acceptable, let alone sound good.
Roland later introduced the SC-55 Sound Canvas, as something of a ‘successor’ to the MT-32. The SC-55 was the first device to also support ‘General MIDI’, which was a standardization of the instrument map, as well as a minimum requirement for various specs, such as polyphony and multi-timbral support. It could be switched to the MT-32 instrument map for backward compatibility.
Where did it go wrong?
While the idea of standardizing MIDI instruments and specs seems like a noble cause, it never quite worked in practice. Firstly, even though you now have defined that program 1 is always a piano, and that you can always find an organ at program 17, there is still no guarantee that things will sound anything alike. Different sound modules will have different methods of sound generation, use different samples, and whatnot, so it never sounds quite the same. What’s worse, if you play an entire piece of music (as is common with games), you use a mix of various instruments. You get something that is more than the ‘sum of its parts’… as in, the fact that each individual instrument may not sound entirely like the one the composer had used, is amplified by them not fitting together in the mix like the composer intended.
In fact, even the SC-55 suffered from this already: While it has an MT-32 ’emulation’ mode, it does not use the same linear arithmetic method of sound generation that the real MT-32 uses, so its instruments sound different. Games that were designed specifically for the MT-32 may sound slightly less than perfect to downright painful.
The second problem is that indeed developers would design sound specifically for the MT-32, and thereby used so-called ‘System Exclusive’ messages to reprogram the sounds of the MT-32 to better fit the composition. As the name already implies, these messages are exclusive to a particular ‘system’, and as such are ignored by other devices. So the SC-55 can play the standard MT-32 sounds, but it cannot handle any non-standard programming.
This leads to a ‘lowest common denominator’ problem: Because there are so many different General MIDI devices out there, it’s impossible to try and program custom sounds on each and every one of them. So you just don’t use it. This is always a problem with standards and extension mechanisms, and reminds me a lot of OpenGL and its extension system.
Today, many years later, General MIDI is still supported by the built-in Windows software synthesizer and most synthesizers and sound modules on the market, and the situation hasn’t really changed: if you just grab a random General MIDI file, it will sound different on all of them, and in many cases it doesn’t even sound that good. The fact that it’s ‘lowest common denominator’ also means that some of the expression and capabilities of synthesizers are lost, and they tend to sound a bit ‘robotic’.
So I think by now it is safe to say that if the goal of General MIDI was to standardize MIDI and make all MIDI sound good everywhere, all the time, it has failed miserably. Hence General MIDI never caught on as a file format for sharing music, and we stopped using it for that purpose many years ago. The ‘classic’ MIDI interface and file format/data are still being used in audio software, but things went more into the direction of custom virtual instruments with VSTi plugins and such, so I don’t think anyone bothers with standardized instrument mapping anymore. The first two parts of MIDI, the interface and the file format, did their job well, and still do to this day.
Getting back to games, various developers would build their music system around MIDI, creating their own dialect or preprocessor. Some interesting examples are IMF by ID software, which preprocesses the MIDI data to OPL2-specific statements, and HERAD by Cryo Interactive.
Doing something ‘custom’ with MIDI was required for at least two reasons:
- Only high-end devices like the IBM Music Feature Card and the MPU-401/MT-32/Sound Canvas could interpret MIDI directly. For other devices, such as PC speaker, PCjr/Tandy audio, AdLib or Game Blaster, you would need to translate the MIDI data to specific commands for each chip to play the right notes.
- Most audio devices tend to be very limited in the number of instruments they can play at a time, and how much polyphony they have.
Especially that second issue is a problem with MIDI. Since MIDI only sends note on/off commands, there is no explicit polyphony. You can just endlessly turn on notes, and have ‘infinite polyphony’ going on. Since MIDI devices tend to be somewhat ‘high-end’, they’ll usually have quite a bit of polyphony. For example, the MT-32 already supports up to 32 voices at a time. It has a simple built-in ‘voice allocation’, so it will dynamically allocate voices to each note that is played, and it will turn off ‘older’ notes when it runs out. With enough polyphony that usually works fine in practice. But if you only have a few voices to start with, even playing chords and a melody at the same time may already cause notes to drop out.
Perhaps it’s interesting to mention the Music Macro Language (MML) here. Like the MIDI file format it was a way to store note data in a way that was independent from the actual hardware. Various early BASIC dialects had support for it. It seemed to especially be popular in Japan, possibly because of the popularity of the MSX platform there. At any rate, where some game developers would build a music system around MIDI, others would build an MML interpreter, usually with their own extensions to make better use of the hardware. Chris Covell did an interesting analysis of the MML interpreter found in some Neo Geo games.
So, trackers then!
Right, so what is the difference between trackers and MIDI anyway? Well, there are some fundamental differences, mainly:
- The instrument data is stored together with the note data. Usually the instruments are actually embedded inside the tracker ‘module’ file, although some early trackers would store the instruments in separate files and reference them from the main file, so that instruments could easily be re-used by multiple songs on a single disk.
- Notes are entered in ‘patterns’, like a 2d matrix of note data, where a pattern is a few bars of music. These patterns are then entered in a ‘sequence’, which determines the order of the song, allowing easy re-use of patterns.
- The columns of the pattern are ‘channels’, where each channel maps directly to a physical voice on the audio hardware, and each channel is monophonic, like the audio hardware is.
- The horizontal ‘rows’ of the pattern make up the timeline. The timing is usually synchronized to the framerate (depending on the system this is usually 50, 60 or 70 Hz), and the tempo is set by how many frames each row should take.
Does that sound limited? Well yes, it does. But there is a method to this madness. Where MIDI is a ‘high-level’ solution for music-related data, which is very flexible and has very high accuracy, trackers are more ‘low-level’. You could argue that MIDI is like C, and trackers are more like assembly. Or, you could think of MIDI as HTML: it describes which components should be on the page, and roughly describes the layout, but different browsers, screen sizes, installed fonts etc will make the same page look slightly different. A tracker however is more like PostScript or PDF: it describes *exactly* what the page looks like. Let’s look at these 4 characteristics of trackers in detail.
Instruments inside/with the file
Trackers started out as being hardware-specific music editors, mainly on C64 and Amiga. As such, they were targeted at a specific music chip and its capabilities. As a result, you can only play tracker modules on the actual hardware (or an emulation thereof). But since it is a complete package of both note data and instrument data, the tracker module defines exactly how the song should sound, unlike MIDI and its General MIDI standard, which merely describe that a certain instrument should be ‘a piano’, or ‘a guitar’ or such.
The most popular form of tracker music is derived from the Amiga and its SoundTracker/NoiseTracker/ProTracker software. I have discussed the Amiga’s Paula sound chip before. It was quite revolutionary at the time in that it used 4 digital sound channels. Therefore, Amiga trackers used digital samples as instruments. Given enough CPU processing power, and a way to output at least a single digital audio stream, it was relatively easy to play Amiga modules on other platforms, so these modules were also used on PC and even Atari ST at times.
Notes entered in patterns
I more or less said it already: trackers use sequences of patterns. I think to explain what a ‘pattern’ is, an image speaks more than a thousand words:
If you are familiar with drum machines, they usually work in a similar way: a ‘pattern’ is a short ‘slice’ of music, usually a few bars. Then you create a song by creating a ‘sequence’ of patterns, where you can re-use the same patterns many times to save time and space.
Patterns are vertically oriented, you usually have 64 rows to place your notes on. What these rows mean ‘rhythmically’ depends on what song speed you choose (so how quickly your rows are played), and how ‘sparsely’ you fill them. For example, you could put 4 bars inside a single pattern. But if you space your notes apart twice as far, and double the speed, it sounds the same, but you only get 2 bars out of the 64 rows now. However, you have gained extra ‘resolution’, because you now have twice the amount of rows in the same time interval.
Pattern columns are ‘voices’
This is perhaps the biggest difference between MIDI and trackers: Any polyphony in a tracker is explicit. Each channel is monophonic, and maps directly to a (monophonic) voice on the hardware. This is especially useful for very limited sound chips that only have a handful of voices (like 3 for the C64 and 4 for the Amiga). MIDI simply sends note on/off events, and there will be some kind of interpreter that converts the MIDI data to the actual hardware, which will have to decide which voices to allocate, and may have to shut down notes when new note on-events arrive and there are no more free voices.
With a tracker, you will explicitly allocate each note you play to a given channel/voice, so you always know which notes will be enabled, and which will be disabled. This allows you to make very effective use of only a very limited number of channels. You can for example ‘weave’ together some drums and a melody or bassline. See for example what Rob Hubbard does here, at around 4:03:
He starts out with just a single channel, weaving together drums and melody. Then he adds a second channel with a bassline and even more percussion. And then the third channel comes in with the main melody and some extra embellishments. He plays way more than 3 parts all together on a chip only capable of 3 channels. That is because he can optimize the use of the hardware by manually picking where every note goes.
Here is another example, by Purple Motion (of Future Crew), using only two channels:
And another 2-channel one by Purple Motion, just because optimization is just that cool:
I suppose these songs give a good idea of just how powerful a tool a tracker can be in capable hands.
The horizontal ‘rows’ of the pattern make up the timeline
This part also has to do with efficiency and optimization, but not in the musical sense. You may recall my earlier articles regarding graphics programming and ‘racing the beam’ and such. Well, of course you will want to play some music while doing your graphics in a game or demo. But you don’t want your music routine to get in the way of your tightly timed pixel pushing. So what you want is to have a way to synchronize your music routine as well. This is why trackers will usually base their timing on the refresh-rate of the display.
For example, Amiga trackers would run at 50 Hz (PAL). That is, your game/demo engine will simply call the music routine once per frame. The speed-command would be a counter of how many frames each row would take. So if you set speed 6, that means that the music routine will count down 6 ‘ticks’ before advancing to the next row.
This allows you to choose when you call the music routine during a frame. So you can reserve a ‘slot’ in your rastertime, usually somewhere in the vertical blank interval, where you play the music. Then you know that by definition the music routine will not do anything during the rest of the frame, so you can do any cycle-exact code you like. The music is explicitly laid out in the row-format to be synchronized this way, allowing for very efficient and controlled replaying in terms of CPU time. The replay routine will only take a handful of scanlines.
With regular MIDI this is not possible. MIDI has very accurate timing, and if you were to just take any MIDI song, you will likely have to process multiple MIDI events during a frame. You never quite know when and where the next MIDI event may pop up. Which is why games generally quantize the MIDI down. However, quantizing it all the way down to around 50 or 60 Hz is not going to work well, so they generally still use a significantly higher frequency, like in the range 240-700 Hz. Which is an acceptable compromise, as long as you’re not trying to race the beam.
Back to the UltraSound
The specific characteristics and advantages of tracker-music should make it clear why it was so popular in the demoscene. And by extension you will probably see why demosceners loved the UltraSound so much: it seems to be ‘custom-made’ for playing sample-based tracker modules. ProTracker modules already sounded very good with 4 channels and 8-bit samples, even if on the PC you needed to dedicate quite a bit of CPU power for a software-mixing routine.
But now there was this hardware that gave you up to 32 channels, supported 16-bit samples, and even better: it did high-quality mixing in hardware, so like on the Amiga it took virtually no CPU time to play music at all. The UltraSound was like a ‘tracker accelerator’ card. If you heard the above examples with just 2 or 3 channels on primitive chips like the C64’s SID and the Amiga’s Paula, you can imagine what was possible with the UltraSound in capable hands.
Where things went wrong for the UltraSound is that trackers were not adopted by a lot of game developers. Which is strange in a way. On the Amiga, most games used one of the popular trackers, usually ProTracker. You would think that this approach would be adopted for the UltraSound as well. But for some reason, many developers treated it as a MIDI device only, and the UltraSound wasn’t nearly as impressive in games as it was in the demoscene.
So, let’s listen to two of my favourite demos from the time the UltraSound reigned supreme in the demoscene. The legendary demo Second Reality has an excellent soundtrack (arguably the highlight of the demo), using ‘only’ 8 channels:
And Triton’s Crystal Dream II also has some beautiful tracked music, again I believe it is ‘only’ 8 channels, certainly not the full 32 that the UltraSound offered (note by the way that the card pictured in the background of the setup menu is an UltraSound card):
What is interesting is that both these groups developed their own trackers. Future Crew developed Scream Tracker, and Triton developed FastTracker. They became the most popular trackers for PC and UltraSound.
So who won in the end? Well, neither did, really. The UltraSound came a bit too late. There were at least three developments that more or less rendered the UltraSound obsolete:
- CPUs quickly became powerful enough to mix up to 32 channels with 16-bit accuracy and linear interpolation in the background, allowing you to get virtually the same quality of tracker music from any sound card with a single stereo 16-bit DAC (such as a Sound Blaster 16 or Pro Audio Spectrum 16) as you do from the UltraSound.
- CD-ROMs became mainstream, and games started to just include CD audio tracks as music, which no sound card could compete with anyway.
- Gaming migrated from DOS to Windows. Where games would access sound hardware directly under DOS, in Windows the sound hardware was abstracted, and you had to go via an API. This API was not particularly suited to a RAM-based wavetable synthesizer like the UltraSound was, so again you were mostly in General MIDI-land.
As for MIDI, point 2 more or less sealed its fate in the end as well, at least as far as games are concerned. Soundtracks are ‘pre-baked’ to CD-tracks or at least digital audio files on a CD, and just streamed through a stereo 16-bit DAC. MIDI has no place there.
I would say that General MIDI has become obsolete altogether. It may still be a supported standard in the market, but I don’t think many people actually use it to listen to music files on their PCs anymore. It just never sounded all that good.
MIDI itself is still widely used as a basis for connecting synthesizers and other equipment together, and most digital audio workstation software will also still be able to import and export standard MIDI files, although they generally have their own internal song format that is an extension of MIDI, which also includes digital audio tracks. Many songs you hear on the radio today probably have some MIDI events in them somewhere.
Trackers are also still used, both in the demoscene, and also in the ‘chiptune’ scene, which is somewhat of a spinoff of the demoscene. Many artists still release tracker songs regularly, and many fans still listen to tracker music.
This is an extraordinary post! I lived through all of this and what a walk down memory lane this is, with excellent detail. Many thanks for putting this out there.
Three years ago I actually built a high-end 486 system identical to the one I had back in 1996, inspired directly by the news that the long dormant GUS-only DOS MOD player, CapaMod, had received an update in 2008, the first since 1996. I still had my GUS, though the PC was long gone (one does not part with a Gravis UltraSound, obviously) — so I built a PC around it. I have a 3-part blog post about the process, with video.
Good stuff! Especially all the tracker history and technology, because that’s something not written about much, but it’s an important part of computing history.
I can’t help but chime in with a few minor additions/corrections.
1) It may be worthwhile to differentiate even more between MIDI and General MIDI. For example FM and MIDI are pretty much completely orthogonal technologies. But once you start talking about using FM for General MIDI (as DOS games did), then yeah, there is a clash.
2) I don’t think there are any filter sweeps with FM, it’s not subtractive synthesis. It might sound similar but the tech behind it is very different.
3) It’s probably fair to say General MIDI is gone as a consumer technology, but it’s certainly not gone. Just look at all those karaoke machines and various band-in-a-box thingies. I don’t think it’s going away anytime soon, but it’s nowadays a professional rather than end-user market.
4) Did the SC-55 really default to the MT-32 instrument map? I don’t think so… And it may be worth mentioning that the first SC-55 modules were not technically General MIDI devices, but the General MIDI standard to a large extent codified a lot of what the SC-55 did. And if you talk about the LAPC-I, might as well mention the SCC-1.
5) The role that video games in general and Sierra On-Line in particular played in creating a market for AdLib, MT-32/LAPC-I, Sound Blaster, and General MIDI probably cannot be overstated. And that loops back to the UltraSound.
Also, RIP Ikutaro Kakehashi.
I wanted to go into trackers on FM chips as well, but this post was already very long, so I left it UltraSound-only, and am doing an FM-oriented post as a follow-up.
As for the role of Sierra… I don’t see it that way personally.
Then again, I grew up with C64 and Amiga. The lacking sound on PC was painfully obvious, so naturally I wanted to get an AdLib or Sound Blaster as soon as they were available (Roland stuff was WAY too expensive).
I didn’t buy it specifically for Sierra games, and in fact, the Sierra games never struck me as having very memorable music.
I would argue that the sound devices sold themselves. Sierra may have been one of the first, but it’s not like they ‘invented’ game music or anything. Every game developer knew they had to get in on the action as soon as an affordable solution arrived for PC, in the form of the AdLib (and according to Rich Heimlich, Sierra wasn’t even the first to market with a game with AdLib support).
Memorable music or not, that is clearly in the eye of the beholder; Sierra published so many games that there were some greats and some duds. I believe Sierra games were the first to support MT-32, Yamaha FB-01, IMFC, and maybe even General MIDI/Sound Canvas. Sierra also acted as a reseller of MT-32 and perhaps some other gear. Sierra had an impact because a) other publishers didn’t want to be behind, and b) there was nothing like hearing a real demo at a store.
The higher-end devices (MT-32, SCC-1/SC-55) definitely did not sell themselves because most buyers weren’t musicians. It was the content (games) that sold the devices, and games were also a huge driver of sound card sales. I mean seriously, why else would you buy a sound card in 1992? All you need is to look at how SB-compatible (games-compatible!) cards sold compared to workhorses like Turtle Beach MultiSound, DAL, RME, and so on.
If you’re going to look into FM, please see if you can find other games besides the first Dune that have great FM music (which doesn’t pretend to be General MIDI and instead takes real advantage of FM synthesis). There’s a lot that can be done with FM, and most games really did FM a disservice.
Not sure it is, really. I think there’s a general consensus on most platforms about which games had some of the best music ever. Heck, you’re proving that point yourself by mentioning Dune as one of the best examples of FM music.
I’m saying that in my perception, the Sierra games aren’t rated as the top in PC game music. I think Monkey Island is one of the highest valued games on MT-32 (and it’s quite good on AdLib as well, by the way).
I’d like to see some actual numbers there though. How many MT-32s did Sierra really sell? And while they were indeed at the forefront of PC game music, they certainly weren’t the only ones. So I’d like to put things in perspective: what other games were out there at about the same time, and what audio did they offer?
I guess this is the core of our difference in perception: to me, MT-32 basically “didn’t exist” back then, as a PC audio device. And as you can tell from these videos by the 8-bit guy and LGR, I’m not the only one:
The MT-32 and IMFC were so expensive that most shops didn’t even stock them, and as such, didn’t demo them either. I don’t recall ever seeing/hearing an IMFC at all, and one was far more likely to encounter an MT-32 in a music store than in a regular computer shop (which is also why Sierra sold the hardware themselves. The average gamer wouldn’t know what to get, or where to get it).
I’ve never known anyone who actually had an MPU-401 and MT-32 or Sound Canvas setup for games back in the late 80s to early 90s.
That stuff was just too expensive. Heck, for many people, a PC was too expensive, so they’d buy game consoles or home computers instead. PC gaming was a niche, and even the ‘entry level’ soundcards like the AdLib were expensive for PC gamers, which only a small percentage of gamers had in those days. Let alone a Roland setup.
I think this MT-32/Sierra stuff is a case of modern revisionist history. The few people interested in oldskool PC games can now afford a real MT-32, and get one from Ebay, or they will use MUNT to get the same experience for free. Then they post some videos on YouTube, which is great and all, but it is by no means an accurate depiction of what oldskool gaming really was like for most people.
Me, I was one of the ‘forerunners’ in my day, and my first sound card was a Sound Blaster Pro 2. Most of my friends had never even considered buying expensive hardware to hear music in games at all (and to put ‘expensive’ in perspective: For the SB Pro 2 I paid about the same as for an Amiga 500 in those days).
But I wasn’t just a gamer, I am also a musician (so I actually bought the one with the MIDI kit, and hooked it up to my Casio MIDI keyboard), and a demoscener. So I had different priorities. Which also explains why I spent another significant amount on a Gravis UltraSound MAX just a few years later (back when others were just getting their first sound card, usually some cheap SB (Pro) clone like a Sound Galaxy). But a Roland? No way. I would have liked one, but not at those prices.
I would love to see how many LAPC-I cards Roland actually sold. I wouldn’t be surprised if even a ‘moderately’ successful card like the UltraSound outsold it by a significant margin.
Michal emphasizes on 1992, maybe in 1988 when King’s Quest IV came out it was rare to have a MT-32, but by 1992 a secondhand AdLib or Sound Blaster was quite common even here in Eastern Europe.
And Sierra was one of the main reason to buy one. Yeah, the scores was not as catchy as C64/Amiga scores, but the reason is partly inspiration: for C64/Amiga it was often krautrock or electronic music, while for Sierra the inspiration was movie scores. In C64/Amiga games music was often in the forefront and the most popular genre was action games. On PC adventure and RPG games were the top sellers for a while and those had more supportive tunes, sometimes with a very good main theme.
See for example the maintheme of Quest for Glory IV(Sierra), which I would say is one of the finest early 1990s PC game track:
Or the soundtrack of Betrayal at Krondor:
Or a few years later Morrowind:
All have strong themes, but the whole OST is more background music than those of the usual C64/Amiga tracks.
From Sierra, I would say Quest for Glory IV and Space Quest III OSTs are amazing, King’s Quest V and Quest for Glory 3 are great, King’s Quest IV is important, because that was the first big PC game score afaik, the others well, I don’t know them too much, LSL and Police Quest did not have too dominant sound track, because of the topic they covered, and I don’t know the later Sierra games as well. Also they owned Dynamix if that counts and they did some great things on Rise of the Dragon.
I don’t think it has much to do with the genre really. Dune has some of the best AdLib music ever made, and that’s clearly a movie-inspired game. It’s also not an action game.
Also, there were plenty of action games on PC as well, but music… just wasn’t a PC thing.
I mean, on C64 and Amiga I can think of a number of games that had such great music, that one would start up the game just to hear it.
On PC, not so much (unless they were direct ports of that great music, like Pinball Dreams and Fantasies for example, but try getting that out of your MT-32… Besides, as I already had an Amiga, and played those games on the real thing, that doesn’t count for me). Nothing comes to mind really. Yea, if I had a PCjr or Tandy, I’d probably listen to the Rob Hubbard songs on those.
I never knew anyone with an MPU-401 back in the day either. But I was a high school kid and about the time when the MT-32 came out, I had just gotten a C-64 (which was great), and I didn’t live in the US so my own experience wasn’t necessarily relevant. These days I know someone my age who had an SCC-1 back in ’92 for music production.
The things did sell, and I’m quite certain the typical buyer wasn’t a high school kid. I also don’t think that there’s any doubt whatsoever that the people composing game music did use MT-32s and later SCC-1s or SC-55s. Would they be really using them if they didn’t expect anyone to hear the music the same way?
How much those devices sold is an excellent question. Do you know of any sales numbers of the GUS? I could not find any kind of numbers, not even ballpark figures. That hints at poor sales, but was it tens of thousands? Hundreds of thousands? No idea.
For the Roland gear, it’s possible to get at least some rough idea from the serial numbers. FWIW, I suspect the LAPC-I specifically sold far less than the MT-32, in no small part because it came much later and was almost immediately obsoleted by the SCC-1.
Sierra gets mentioned because they really were one of the first, and they really put some effort into marketing. I don’t think anyone suggested that Sierra was the only company, certainly not.
Oh, re sales numbers: Sound Blaster: The Official Book, written sometime in 1992, says (page 27) that “today there are over one million Sound Blasters in use, in addition to thousands of Sound Blaster Pros”. That text was written about the time the SB16 came out. Just so you know that with an SB Pro, you were more special than you might think!
You know, this sounds a lot like a false dilemma.
I see it the same way as GLQuake: when it was released, there was hardly any hardware out there that could run it (the readme literally says that). ID made it however ‘because they could’, and it would be fun for people who were early adopters of 3d accelerators.
Roland stuff in games is the same way: developers supported it, because they could. Not because there was this huge installed-base (or that they expected a huge installed-base to arrive soon). So yes, they expected ‘some people’ to hear the music, and they probably loved just composing with the hardware themselves, because it was a significant step up from the mainstream audio. But it wasn’t for the masses.
Just like today’s games with all these detail levels. Yes, in theory you can run it at ultra detail with 16xAA at 4k resolution. Doesn’t mean many people have the hardware to actually play the game that way.
The majority of gamers probably has to run the game at ‘medium’ detail in 1080 res or whatever.
I have no idea. All I know is that every scener seemed to have one, back in the day 🙂
I know of only one scene-group that ever supported any Roland stuff, The Phoney Coders: http://www.pouet.net/groups.php?which=1451
Their demos are captured on MT-32 here: https://youtu.be/Y9jJYVM-dq0
Yea… I just went for the more high-end model when I was ready to buy my first card. The Pro had just been released, and I suppose they aimed it more at the musician, with the MIDI kit they offered in a bundle (which is the one I got).
It was significantly more expensive than the regular SBs. I suppose it didn’t help that games largely ignored the extra capabilities of the SB Pro and newer cards, and mostly stuck to OPL2 and mono digital audio. So for gamers there wasn’t much reason to pay the premium for the SB Pro.
I think the explanation for widespread support of Roland/General MIDI was much more prosaic, that was what the composers used. Basically publishers got that for free, even knowing that only a minority (tiny minority?) of players would hear the music that way.
Re SB Pro and games, at least it got some support. Not like SB16 which was pretty much utterly ignored by games — because every clone offered SB Pro compatibility and not SB16, because 16-bit samples were too big, and because crappy noisy sound effects were perfectly fine in 8-bit.
That isn’t necessarily true.
If you use tracker-based tools, you would never actually have to use MIDI at all, certainly not General MIDI.
And if you write music specifically for (PC) audio devices, then General MIDI doesn’t have much of a place usually, because you’ll want to use sounds that suit the hardware, rather than trying to shoehorn your music into generic poor implementations of GM instruments (although in practice that is what happened with AdLib on many occasions).
So you still have to put in the effort to make game music on an MT-32 or Sound Canvas. You certainly don’t get it ‘for free’ just because you made some music for a game.
You would have to make a conscious choice of ‘MIDI first’ in your workflow, if you want MT-32/Sound Canvas music ‘for free’. And that was not the usual workflow in game development in general. Because, as the article already explains, MIDI doesn’t suit primitive sound devices very well. You’re better off with something tracker-like.
Back in the 1990s Computer Gaming World advertised gaming PCs starting around 2500$ and going up to 4000$ and they benchmarked those PCs time to time. I think it is the same unrealistic thing what DigitalFoundry does nowadays with the 500$ Ryzen CPU. Who the hack spends so much money on hardware only to play games???
It’s interesting to look at all this and recall that Microsoft ended support for discrete audio channel hardware in Windows Vistas — just 2-channel, software mixed from then on. CPUs are so fast and parallel nowadays that the mixing is indeed more or less negligible. It’s less “fun” though. The reason I built that 5×86 PC to play those MODS from way back when is so I could do it through the GUS, knowing it’s a weak CPU doing what it could not, otherwise, and that it’s (linear) interpolating the samples and upscaling to 16-bit, etc. all in hardware and at no cost to the host CPU.
Computer Gaming World, June 1992, page 88: “LAPC-I or CM-32L: The Roland synthesizer cards are the ultimate in music sound cards. […] The price is quite high at approximately $450 (street price) for the LAPC-I and around $500 or more for the CM-32L. […] To hear one is to buy one.” Emphasis on the last part. How many readers actually thought that is the real question!
I’m not sure I agree actually.
Perhaps I’m ‘spoilt’ by the C64 and Amiga, but to me, MT-32, Sound Canvas or any other MIDI devices always had this ‘corny’, ‘robotic’, artificial vibe. Just listen to those Phoney Coders demos. Then start any demo with tracker-based music, either any Amiga demo, or a PC demo from around the same time, like Crystal Dream. I certainly prefer the tracker stuff, it sounds a lot more like ‘real’ music, not some elevator/ringtone/kitsch thing.
I quoted what computer game magazine writers published back in ’92. I’m sure not everyone agreed back then either. About Roland synths specifically, some say they’re too sugary and synthetic and kitschy, others say they’re warm and lush and buttery smooth. I’m more in the latter camp but it’s just like with any other instrument — it can be played badly or it can be played well. The player (composer) makes the real difference, not the instrument.
Re Sierra, here’s Computer Gaming World, Oct 1989, page 8, Game of the Year Awards: “CGW’s 1989 Special Award for Achievement in Sound goes to Sierra […] for Space Quest III: Pirates of Pestulon […] The Roland MT-32 reproduces Space Quest III’s sound with quality that will delight the most discriminating audiophile. Although the Ad Lib card’s sound is not quite as rich, the soundtrack on the Ad Lib still shines exponentially better than any other game’s audio to date.” So either it’s not revisionist history or CGW was in on it back in ’89 🙂
Re selling hardware, Sierra in ’89 apparently offered audio cassettes (cheap? free?) with recordings of their game music playing on MT-32 and AdLib. Clever, and so 80s.
I don’t think that really covers it. See what I said in the article above about the ‘mix’.
You see, musicians use instruments differently from PC games:
1) They don’t necessarily use a single synthesizer for an entire song. They pick the synthesizer that sounds best for each individual part.
2) They don’t necessarily run the signal ‘dry’: they may add outboard effects like eq, reverb, chorus, delay and whatnot, to flesh out the basic sound.
Clearly, Roland’s products shine in that situation. They offer some great basic sounds, and the quality of the produced sound is very good, so you can easily shape/finetune it with effects.
But in a game you can’t do any of that. All sounds have to come from the same synthesizer, and they have to be used ‘as-is’. And I think that’s where the ‘kitsch’-sound comes from, mainly. Firstly because after a few songs you start to recognize the same sounds all the time. Secondly, because not all sounds necessarily fit the song that well.
Sample-based trackers don’t have that problem: you can pick any samples you like for all parts in the song. And you can also pre-apply certain effects like eq, reverb, chorus or such to the sample.
They sound more like ‘real’ music, because they are more similar to ‘real’ music this way.
That’s not what I said (just like I never said that MT-32 was the default map for a Sound Canvas for example).
I said the ‘revisionist history’ was in that today people seem to think that lots of gamers used MT-32. While in reality, they were so rare and expensive, that most gamers never even *heard* what MT-32 sounded like, because they didn’t know anyone who owned such a setup, and PC shops generally didn’t even carry Roland products.
And going from the assumption that the MT-32 was a huge success, like ‘the standard’ in PC game music, they give Sierra lots of credit for pushing the MT-32 and creating that ‘standard’.
Sierra deserves credit for being an early adopter of PC audio devices, and in a way they did somewhat ‘standardize’ the MT-32 on the PC platform. But it’s not like it was a big hit. Or that Sierra ‘invented’ music in games or however far some people want to push the myth.
But PC people wouldn’t know that. Game music evolved mostly on home computers like the C64. People like Rob Hubbard did way way more than Sierra for game music. And also made way more legendary music. You can’t even begin to compare them.
The few things that Rob Hubbard did on PC, or more specifically, PCjr/Tandy, are also amazing.
Listen to the music he made for Kings of the Beach, One on One, 688 Attack Sub and Skate or Die.
Then compare it to the PCjr/Tandy music that Sierra made.
Sierra supported audio devices, Hubbard actually made the audio devices sing.
Yes, but again, how many people actually got those? I’ve never seen/heard one.
You wrote: “Roland later introduced the SC-55 Sound Canvas, as something of a ‘successor’ to the MT-32. It defaulted to the MT-32 instrument map.” I read that as “the SC-55 used the MT-32 instrument map by default”, but apparently that’s not what you were trying to get across. Yet I don’t know how else to understand that statement. Where did I go wrong?
There’s no question Rob Hubbard did great work, and he was able to get a great deal out of very little. I think people like Mark Seibert or Robert Holmes did work that’s just as memorable, though very different, and they worked in a completely different environment. If you believe they can’t be compared, that most likely indicates you let your personal biases take over. I have obviously personal biases too, and I can never completely suppress them. All I can do is accept that other people have different experiences which are no more or less valid than mine, and I can try to judge where the “mainstream” tastes and opinions lie (or lay 25+ years ago, in this case).
By the way, if you haven’t read it, you might find the book “Game Sound” by Karen Collins (MIT Press) interesting.
No, it’s so completely not what I wanted to get across, that I have no idea how that even got there. Must be because I wrote it in many sittings, and sometimes copy-paste some stuff as placeholder/reminder.
I only re-read the first part of the article, which said:
“Roland Sound Canvas set another standard (General MIDI), and also included an MT-32 compatibility mode (which wasn’t quite 100% though).”
I didn’t recall there was a second mention of the SC lateron (it’s more or less superfluous).
Nevermind, my fault, sorry about that!
I think the ‘bias’ thing is a little bit too easy (and often used by people losing an argument). So let’s never mention that again.
Personally, I wouldn’t even know who Mark Seibert and Robert Holmes are, without googling them. I’m sure they were some musicians that worked on some reasonably popular games, but they’re not exactly ‘household names’. Rob Hubbard however, is, at least, as far as people interested in game music from that era are concerned.
Do you realize that Rob Hubbard was far more than just a musician, but also a very capable programmer, who almost singlehandedly put game music on the map on the C64 and various other platforms?
Most other C64 musicians/programmers started with a reverse-engineered replay routine from Hubbard, and modern trackers pretty much started from there.
See this for some valuable background info on Hubbard’s work: http://www.1xn.org/text/C64/rob_hubbards_music.txt
Nothing on PC compares really, because PC never made any worthwhile contribution to game music technology. They either used something MIDI-based, which originated in the synthesizer world with Roland and other manufacturers teaming up, at around the time IBM was still designing the first PC, so years before any PC soundcard.
Or they use tracker-based technology, which originated from the world of the C64 and other home computers or game consoles.
So okay, I’ll google them.
So, Mark Seibert was the main composer for Sierra in the early days, and I suppose Robert Holmes also did work on some games from Sierra.
Seibert does not appear to have done any programming at all, and Holmes has done some programming, but it doesn’t look like anything was audio-related.
Which might also explain why you can’t compare them with Hubbard: They merely used audio technology (which probably was written by programmers with little or no musical background, MPU-401/MT-32 is just standard MIDI equipment playing standard MIDI data. At best that makes Seibert and Holmes good ‘conventional’ composers, but nothing more), they did not develop it, let alone push the envelope, and create sounds never heard before.
Hubbard did. Hubbard and many other musicians of his generation were both musicians and programmers, which allowed them to just write the code for whatever sounds they had in mind. They weren’t bound by the abilities and limitations of a third-party system.
Hubbard is as far as I know the only one who used sampled instruments on a stock PCjr/Tandy. This puts his music on the platform in a league of its own.
Which in a way is rather sad: Hubbard’s main platform was the C64, and he just took his ideas from C64 and found ways to make them a reality on PCjr/Tandy as well, a platform where he was merely a ‘guest’. Yet none of the main developers for the platform ever pushed it anywhere near that level.
The same goes for tracker-based music: Ex-Amiga developers such as Triton simply brought the ProTracker technology to PC.
And arguably the best AdLib tracker out there is EdLib, which is written by JCH, who originally worked on C64, and developed various music editors there. Like Hubbard, he brought the C64 technology to the PC/AdLib, and pushed it beyond where regular PC developers went.
Thanks for clearing up the SC-55/MT-32 thing.
I used both the C64 and PCs long enough to realize that there was one massive difference: The C64 was static while the PC was (and is) constantly evolving. That has a perverse effect. By the time the C64 was completely obsolete, programmers learned how to make it do things that were considered utterly impossible when the C64 was new. On the PC, that never happens (except in the retro programming scene!) because by the time some piece of hardware is truly well understood, it is already obsolete and uninteresting. For commercial software the big problem is the wide variety of PC hardware that needs to be supported, which completely kills many nifty low-level tricks that were doable on a C64.
So on the one hand you have obsolete tech used to the max (C64), on the other you have constantly evolving and improving tech that is poorly understood (PC). In a way the PC way of doing things is a real shame and a waste of perfectly good tech, but it’s also proven to be completely unstoppable.
And yes, folks like Seibert or Holmes were “conventional composers”. I honestly thought you were talking about memorable music, but now I see that you had something slightly different in mind. I really don’t know how many people would recognize names like Hubbard or Seibert, I suspect that in total it’s not going to be a lot for either of them.
Hardware-wise perhaps, but software-wise, the C64 also evolved. Hubbard played a significant role in that, on the audio side.
I think it’s too easy an excuse to say ‘PC hardware evolves, so there’s no reason to do anything more than lowest-common-denominator stuff’.
Developers did a lot to push the envelope in graphics on PC, with stuff like Wolfenstein 3D, DOOM, Quake and such.
Why couldn’t you do the same with audio? Sound cards didn’t evolve as quickly as video cards did.
One doesn’t go without the other.
Hubbard’s music is catchy, partly also because his compositions are sometimes partly covers of other music (International Karate references Merry Christmas, Mr. Lawrence). But more than just being good music to listen to, it was memorably because it pushed the boundaries. Nobody had unlocked the power of the SID yet. Hubbard understood what it was that Bob Yannes had designed: a subtractive synthesizer. And he wrote routines to use it as such, rather than just a ‘dumb’ device that plays notes with some ‘preset’ instruments.
Nobody heard music like that from a C64 before.
Likewise with Skate or Die… People had found a way to play 4-bit samples on the SID… But Hubbard turned that ‘sample channel’ into a 1-track ‘MOD player’ (before MODs were a thing), and played a guitar solo with bends and slides and everything, combining it with the regular channels of the SID (he did basically the same with the SN76489 chip found in the PCjr and Tandy).
The first time you hear a distorted guitar coming from your C64 leaves a lasting impression.
The Sierra music is good, but nothing groundbreaking.
The most groundbreaking stuff I heard on PC is probably the Second Reality soundtrack. I knew mods, but this was the first ‘next-level’ tracker music for me. More channels, larger, better quality samples, and an incredible composition that fits the visuals perfectly, speeding up and slowing down etc.
It might have had slightly less impact if I had seen Desert Dream before (the Amiga demo that inspired Future Crew), but even then, it’s an epic piece of work.
Hubbard recently received a honorary doctorate of music from Abertay University: http://www.gamasutra.com/view/news/285705/C64_game_musician_Rob_Hubbard_recognized_with_honorary_degree.php
Even the BBC reported on that.
Pretty sure he is the most well-known game musician by a margin.
That’s exactly my point, the C64 software evolved (and evolved amazingly far) with the hardware remaining static. Evolving PC hardware and supporting the lowest common denominator are fairly orthogonal concepts. If Sierra only cared about the lowest common denominator, would they ever support the IMFC or FB-01 or MT-32 or SC-55?
The huge, huge difference between graphics and audio was that for a good while (circa 1990-1995), there was a single baseline: VGA (and for a while, VESA VBE). That enabled folks to invent things like Mode X with direct register twiddling and using the hardware in a creative way. But they didn’t care about EGA or XGA or whatever.
On the audio side… for digitized audio, you had Sound Blaster as a baseline, and the best you could do with that was play audio without cracks/glitches (and you know very well even that wasn’t always easy!). Creativity was maybe writing a real-time mixing engine like you had in DOOM, but basically all you could do was dump samples to the hardware at a constant rate.
On the music side the baseline (again 1990-1995) was AdLib, a poor abused thing which no one liked much. The problem was that even in 1990, AdLib was considered inferior to a MT-32, and soon there was the SC-55, Wave Blaster, CD-ROM audio, and all that stuff. Heck, even Ensoniq (Bob Yannes again!) got involved in 1993 or so with their SoundScape.
So the graphics guys just tried to get the most out of VGA/SVGA. But the audio guys had a dilemma: How much effort to put into mediocre hardware that almost everyone had (AdLib) vs. much better but also much rarer hardware (MT-32, GUS, GS/GM). Just the requirement to support all the disparate sound hardware inevitably meant that quality suffered — instead of writing to one VGA/SVGA interface, there were at least two or three. But that was the reality, and ignoring reality is dangerous business, as both politicians and entrepreneurs know.
Google for “most famous game musician”. You’ll see just how much people’s own experiences shape their perception, and how little Rob Hubbard is known.
I have to say that this is a very interesting discussion.
And my point is that the software didn’t evolve just because the hardware remained static. People were making an effort to evolve that software. People like Rob Hubbard.
I meant ‘lowest common denominator’ in the same context as in the original article: what all sound devices have in common is that they play certain notes on certain instruments. MIDI events are a simple way to store that data. To support each device you just need to implement two things:
1) The actual instruments for the specific device
2) a translation from MIDI events to commands for the specific device (which in the case of the IMFC is not required, since it supports MIDI natively)
So ‘lowest common denominator’ means: you just make music with the basic stuff that all devices support. You don’t do anything specific for specific devices (unlike what Rob Hubbard did on the PCjr/Tandy version of the 4 games I mentioned earlier).
Sierra’s IMFC/FB-01 support was not much more than ‘tickbox’ level: the FB-01 driver is riddled with bugs, sending invalid commands and whatnot, percussion is missing etc. And even on the IMFC, the music doesn’t sound very good. It sounds like a very basic ‘port’ of the MT-32 music with some instruments they quickly hacked together.
The OPL2 wasn’t that bad really. Certainly beats an Atari ST or Tandy. Yet in all those years of OPL2-devices, hardly anyone ever really dug into that chip. It requires special skills: you need to know how to program an FM synthesizer, and you need to know how to program an audio routine for a game. It helps if you also know how to compose music yourself, so you know what you should be developing to get good sound. Hubbard combined those skills, as did JCH.
Really? I don’t know what planet you’re from, but over here, AdLib and MT-32 or other solutions were never even remotely seen as competitors, due to the insane price difference.
Wave Blaster and such never took off either. Only CD-ROM eventually replaced on-board synthesizer chips, but that wasn’t until 1995ish. Which is some 8 years after the AdLib was introduced.
You see, it’s not a dilemma, for the exact reason you mention: AdLib was the hardware that almost everyone had.
The Tandy/PCjr audio chip wasn’t great either, and the SID was quite primitive as well, even by AdLib standards.
But they were the chips that everyone had, so you dug into them and made the most of it. Why did this not happen in the PC world?
I think it’s just that mindset, the one you’re showing here as well. “Oh, we’ll just go for the easy way out, there will be better hardware out next year anyway, so why even bother?”.
There were only a few PC devs that went: “So what if there’s new hardware next year? I’m making a game NOW, and I want to make the best game ever! Besides, there will still be plenty of people using this hardware next year!”
The development of RealSound is an excellent example of that mindset: yea, sure there’s audio devices on the market. But why not make that internal speaker sound good, if you can?
Having said that, AdLib is the most widely supported audio device in DOS games: http://www.mobygames.com/attribute/sheet/attributeId,21/
MT-32 is second: http://www.mobygames.com/attribute/sheet/attributeId,35/p,2/
(Or actually, Sound Blaster is, but its synth is an AdLib of course: http://www.mobygames.com/attribute/sheet/attributeId,17/)
Most other stuff is only supported by a handful of games and/or supported indirectly, because they’re GM-compatible and can be used with games that were designed to support a Sound Canvas.
Not to mention that quite a few games with MT-32 support still require you to have a Sound Blaster for any sound effects, making the cost of the MT-32 for gaming even higher.
As if that proves anything.
Hubbard has a sort of cult status in the C64 scene. There’s even some demos dedicated to him and his music: http://www.pouet.net/search.php?what=hubbard&type=prod
VGMPF also says it: http://www.vgmpf.com/Wiki/index.php?title=Rob_Hubbard
“Rob Hubbard is a British composer and sound designer who is known to be one of the most (if not the most) renowned video game musician of all time.”
Did you already read that disassembly of Hubbard’s routine from the link I posted earlier? It might be an eye-opener for you.
While reading up on General MIDI, I realized that Stanley Jungleib’s infamous(?) ‘274 patent (see https://www.google.com/patents/US5886274 and http://seersystems.com/1999/03/22/what-exactly-is-the-274-patent/ ) describes a technology that is in effect a hybrid of trackers and MIDI. The short summary is a packaged MIDI sequence with sound banks included. It goes beyond trackers because the instruments might use FM synthesis or physical modeling etc., not just waveforms, but the basic idea is exactly the same: Provide a single file which defines a musical sequence in very fine detail and which will sound more or less the same when played on any system.
See also http://www.jungleib.com/1995/07/02/general-midi-book/ if you can stomach the presentation; especially the GM2000 section on pages 188-190. There is absolutely no mention of trackers anywhere that I can see, but from a completely different angle and about 10 years later, Jungleib arrived at something which suspiciously resembles a tracker module on steroids (or more like a truckload of illegal performance-enhancing drugs).
The technology sounds quite reasonable but it never took off, and the reason for it is pretty obvious (the letters M, P, and the number 3).
Trackers aren’t necessarily waveform-based. I tried to point that out already in this article, by using some C64 music as an example of tracked music.
There are also trackers for eg Gameboy or even AdLib, and some trackers even support both waveforms and FM simultaneously, such as Scream Tracker 3 and Renaissance’s CDFM.
And there are also examples of waveform + ‘native’ synth on C64 and SN76489 among others.
Check this one out for example: https://youtu.be/uSk9qE6_2Oc
Two SID-channels are used ‘natively’, the third is transformed into a DAC and plays multiple waveform-based tracks with software-mixing.
Thing is, because MIDI is very generic and flexible, you could theoretically make it do the same as trackers, by using SysEx and limiting the polyphony and timing for your specific target scenario.
But it isn’t very practical or efficient.
Also, I have no idea where he gets that 190 MHz figure from, when talking about PCI. Standard PCI is just 33 MHz, and v2.1 can do 66 MHz, but that’s about it.
Yeah, I don’t know about the 190 MHz. 190 MB/s would make more sense as a bandwidth figure from ~1995, but not really for PCI.
I’ve seen a couple of AdLib/OPL3 trackers and yeah, it’s a thing. I suppose I need to distinguish between trackers as a method of arranging music and modules as self-contained musical pieces. The thing is that the hardware-specific trackers/modules need that specific hardware, or very precise emulation, and waveform-based modules don’t.
As far as I know, MIDI + DLS actually makes it possible to distribute completely self-contained MIDI files with all instruments, so the mechanism for MIDI “modules” was standardized in the late 1990s, but I don’t think it’s widespread at all. Could have been different if they’d thought of that ~10 years earlier, but by 1997 MP3 made any such technology impractical as a mainstream thing.
I would argue that this is not the case. At best, emulation of waveform-based hardware is generally simpler than other types of synthesis.
But you very much need to actually emulate a lot of basic characteristics of the Amiga sound chip (and the quirks of the replay routine itself) in order to play a ProTracker module correctly.
Early MOD players on PC were notorious for getting a lot of things wrong.
Also, if you look at eg FastTracker II, it introduced things like pingpong-looping. Not all wavetable-based hardware is capable of this. For example, the Amiga cannot do this. It can only play samples forward, not backward. You would have to rely on some kind of emulation for this.
I’m not sure what the use-case would be for this though. It doesn’t solve the problem that you need the actual hardware to play the instruments embedded in the MIDI file/module.
I mean, technically the MT-32 and FB-01 music for early Sierra games is like a ‘module’ as well: they include SysEx data that initializes instruments.
But it only works correctly if you actually have an MT-32. A Sound Canvas is ‘MT-32’-compatible, but since it has different hardware, it cannot perform all SysEx operations correctly, and therefore it will not sound the same.
So the only way would be to ‘standardize’ a specific synthesizer implementation, and make sure that all replayers can emulate that 100%. Which effectively is the same as what happened with the popular Amiga MOD formats and various related tracker formats, such as S3M and XM, or perhaps even more accurately, the SID format.
SID files are literally the 6510 CPU code extracted from a C64 application. Any SID player will need to actually emulate both the 6510 CPU and the SID chip. The 6510 code will perform raw writes to SID registers.
The VGM format is somewhat related: it’s a capture of register writes from an emulator. You can either replay it on real hardware by doing the actual register writes to the actual hardware, or you can send the register writes to an emulator for the particular sound chip.
In related news, I should be adding 2 or 3 “new” UltraSounds to the ones I already have. It is fascinating hardware, that’s for sure.
And I’m looking forward to your next post.
Wonder if anyone could report their GUS serial numbers at http://www.os2museum.com/wp/how-many-gravis-ultrasounds/ Surely we can figure out how many there were?
Pingback: Putting the things together, part 2: MIDI and other problems | Scali's OpenBlog™
Pingback: Do 8-bit DACs result in 8-bit audio quality? | Scali's OpenBlog™