Sierra & Roland D-110 Synthesizer MP3 Demonstration

[Cloudschatze]

Roland D-110 playback.

Conquests of Camelot
Main Title Theme
Camelot Castle
Gwenhyver
The Black Knight Cometh

Hero's Quest
Introduction
Erana's Peace
Fairy Ring Medley

Hoyle's Book of Games, Volume 1
Main Title Theme
Craaaazy Eights

Leisure Suit Larry 3
Nontoonyt Island Song The bender range isn't quite right in peachy-peach peach-land.

Police Quest II
Main Title Theme

Quest for Glory II
Title and Introduction What is the sound of one hand clapping a mountainside?
The Rubiyat of Omar

Space Quest III
Introduction

I believe the playback dissimilarity, when compared to the MT-32, is mostly due to the preset timbre differences. Sierra probably could have dumped and edited the relevant MT-32 timbre data for use as custom timbres, but instead, they chose the closest matching instrument, not unlike other patch-map conversions. The custom timbres they did use translate well, for the most part. Furthermore, since several of the default timbres utilize more partials than the MT-32 counterparts, noticeable polyphony dropouts occur.

[Tom]

Fascinating.  These are all very passible for MT-32 soundtracks.  Though there's obvious differences in sound characteristics, they match the MT-32's output better than any other device would.  Thanks for recording these!

[Cloudschatze]

So, I'm looking into some things, and... good golly, just look at this nonsense:

MT-32         D-110         D-10

partial   =   partial   =   partial
timbre    =   tone      =   tone
patch     =   timbre    =   timbre
n/a       =   patch     =   n/a
n/a       =   n/a       =   patch

Maybe they should have had a few more group meetings, or something. 

[Great Hierophant]

From reading the manuals, I was under the belief that the MT-32 and D-110 had 128 preset timbres/patches, 34 drum patches and memory for 64 custom patches.  If this is true, I don't believe Sierra may have had enough room to load both the their custom patches and patches ripped from the MT-32.  Maybe they were trying to avoid the similar IP issues that Munt faced fifteen years later.  Also, is it possible to rip the data for the preset patches without having to reverse engineer the MT-32?  Is it possible the alternative to a digital rip of the patch data was to play it by ear?

[Cloudschatze]

If this is true, I don't believe Sierra may have had enough room to load both the their custom patches and patches ripped from the MT-32.

It depends on the game. Most (if not all) aren't sending an entire bank of 64.

Maybe they were trying to avoid the similar IP issues that Munt faced fifteen years later.  Also, is it possible to rip the data for the preset patches without having to reverse engineer the MT-32?  Is it possible the alternative to a digital rip of the patch data was to play it by ear?

Munt's problem is with the actual PCM waveforms, not patch data. Since the samples are already present in the synth, Sierra wouldn't have run into the same issue. Extracting the data wouldn't have been terribly difficult, but I think it comes down to the time and effort that would have been involved, and possibly personal preference. Mark may have liked the D-synth tone equivalents.

[NewRisingSUn]

So, I'm not sure if changing the parts to MIDI channels 2 - 9 is the correct thing to do. Leaving the channels at 1 - 8 and muting part 1 seems to produce better results (IMO).

That's certainly wrong. Channel 1 contains PC speaker data.

From reading the manuals, I was under the belief that the MT-32 and D-110 had 128 preset timbres/patches, 34 drum patches and memory for 64 custom patches.

PLEASE get the terminology right --- as Cloudschatze has shown above, it's confusing enough when saying it right, but you're making a mess when you get it wrong. An MT-32 patch is something different from a timbre. The MT-32 has 128 patches, which point to 128 preset melodic timbres. Each of these 128 patches can be made to point to any of the 128 preset melodic timbres, any of the 64 memory timbres, or any of the 30 preset rhythm timbres.

If this is true, I don't believe Sierra may have had enough room to load both the their custom patches and patches ripped (sic) from the MT-32.

True.

Maybe they were trying to avoid the similar IP issues that Munt faced fifteen years later.

Unlikely. Some of their custom timbres are the default timbres with only one or two bytes changed.

Also, is it possible to rip the data for the preset patches without having to reverse engineer the MT-32?  Is it possible the alternative to a digital rip of the patch data was to play it by ear?

What exactly do you think the word "rip" means? Certainly not what you think it means. Anyway, the data for a default timbre may be obtained by sending a program change message indexing a patch that points to that timbre, causing the timbre data to be loaded into that part's TIMBRE TEMP AREA, then requesting the 246 bytes from the TIMBRE TEMP AREA (02 00 00), Device-ID=part#.

[Great Hierophant]

After a careful perusal of Roland's MT-32 manual, I am still having some trouble distinguishing a timbre from a patch.  According to the manual, the Roland MT-32 has 128 preset timbres.  A patch is a particular timbre with (additional) assigned musical data.  However, the manual talks about assigning timbres to parts, not patches.  But it also says that the Roland MT-32 has 128 built in patches!  What I believe this to mean is that Roland had preset/default patch data for each (or all) of the preset timbres loaded when the device is turned on. 

"Ripped" is not the right word when I was talking about transplanting timbre parameters from the MT-32 to the D-110.  This assumes that you can simply take the partial parameters for each timbre from the MT-32 and apply them to the D-110.  A cursory perusal of both suggests you can.  So, if the game uses no more than 64 custom + preset patches, you can make the D-110 sound exactly like the MT-32.   

[NewRisingSUn]

After a careful perusal of Roland's MT-32 manual, I am still having some trouble distinguishing a timbre from a patch.

It's actually very easy:

A "timbre" is just an instrument. Plain and simple.

A "patch" is a bunch of settings (reverb switch, bender range, tuning) plus a pointer to a timbre. When a Program Change message is received (Cx vv), the reverb/bend range/tuning settings from the vv-th "patch" are applied to channel x, and the timbre to which the vv-th patch points to is applied to channel x (or "assigned", whatever you want to call it).

Since vv can take 128 values, there are 128 patches in the patch memory. By default, the 128 patches all have the same settings and point to the 128 preset melodic timbres (there are 128 preset melodic timbres, 30 preset rhythm timbres and memory for 64 custom timbres).
To play a custom timbre, you load it into the custom timbre memory, then make one of the patches point to it, then select that patch with a Program Change message.

If you've ever programmed in C: The vv of a program change message is the index into an array of patches, each of which contains an index into an array of timbres.

"Ripped" is not the right word when I was talking about transplanting timbre parameters from the MT-32 to the D-110.

To "rip" means "to tear or split apart or open". For game music, this means that you open the game's data files and take the data directly ("rip it out of the data files"), instead of capturing and writing down sound card register writes (that would be a "log" instead of a "rip") or recording the audio/MIDI transmission (that would be an "audio/MIDI recording" instead of a "rip") as the game runs and plays back the music. For timbre data, it means extracting the data from the original control ROM, as opposed to requesting it from the unit with an RQ1 or RQD system exclusive message.

[Cloudschatze]

So, I'm not sure if changing the parts to MIDI channels 2 - 9 is the correct thing to do. Leaving the channels at 1 - 8 and muting part 1 seems to produce better results (IMO).

That's certainly wrong. Channel 1 contains PC speaker data.

This whole adventure had been an exercise in varying degrees of wrongness.

Here is an example of the PQ2 introduction with parts 1 - 8 mapped to MIDI channels 2 - 9:
PQ2 Intro, again

And here is an example of the same, but with part 8 manually muted:
PQ2 Intro, yet again

If this is true, I don't believe Sierra may have had enough room to load both the their custom patches and patches ripped (sic) from the MT-32.

True.

What game uses all 64 custom timbres, even if an entire bank is sent? Even one or two of the MT-32 timbres would have made a significant difference in the overall sound.

Since vv can take 128 values, there are 128 patches in the patch memory. By default, the 128 patches all have the same settings and point to the 128 preset melodic timbres (there are 128 preset melodic timbres, 30 preset rhythm timbres and memory for 64 custom timbres).
To play a custom timbre, you load it into the custom timbre memory, then make one of the patches point to it, then select that patch with a Program Change message.

This is what makes these synths so cool. How many other synths from the late eighties can be made General MIDI instrument-compatible (other than *possibly* the Proteus 1)?

Oh, I checked just Conquests of Camelot for D-110 patches, but didn't encounter any.

[NewRisingSUn]

This whole adventure had been an exercise in varying degrees of wrongness.

The MT-32 driver sends a system exclusive message disabling the channels that shouldn't be played; I image the D-110 driver doing the same. For some reason, the D-10 doesn't get that.

[Cloudschatze]

This whole adventure had been an exercise in varying degrees of wrongness.

The MT-32 driver sends a system exclusive message disabling the channels that shouldn't be played; I image the D-110 driver doing the same. For some reason, the D-10 doesn't get that.

Ah! You just hit the nail on the head.

Here is the specific SysEx message that is transmitted with both the MT-32 and D-110 drivers:

F0 41 10 16 12 10 00 0D 01 02 03 04 05 06 07 10 09 2E F7

Which breaks down into:

Part 1 - MIDI channel 2
Part 2 - MIDI channel 3
Part 3 - MIDI channel 4
Part 4 - MIDI channel 5
Part 5 - MIDI channel 6
Part 6 - MIDI channel 7
Part 7 - MIDI channel 8
Part 8 - MIDI channel Off
Part R - MIDI channel 10

And, you're right, the D-10 ignores this message (it's not part of the MIDI implementation), whereas it's valid for use with the D-110.

So, for anyone interested, you'll have to manually configure a D-10 with this part-to-MIDI mapping.


Guess I need to re-record some stuff...

[Great Hierophant]

For timbre data, it means extracting the data from the original control ROM, as opposed to requesting it from the unit with an RQ1 or RQD system exclusive message.

I hate to continue to be a bother, but I wonder how the default timbre settings can be stored in the control ROM.  Each timbre can take up 1-4 partials, and and each partial takes up 58 bytes to store its parameters.  If I added correctly, the 128 preset timbres use a total of 314 partials.  This equals 18,212 bytes.  For the 34 Rhythm timbres (4 of which are repeated one key lower), 42 partials are used.  If the Rhythm tibres work in the same way, that is another 2,436 bytes.  The 33 Rhythm tibres of the CM-32L use another 82 partials, for an additional 4,756 bytes, assuming the previous sentence is correct.  You also have to add another 15 bytes for the common parameter for each timbre, which equals 2,430 and 2,925 for the MT-32 and CM-32L, respectively.  I believe the MT-32 control rom is 64K, 65535 bytes.  So, just to contain the default timbres, the MT-32 requires 23,078 bytes to store the default timbres in its control ROM, 25,893 bytes for the CM-32L.  Is this correct? 

The MT-32 driver sends a system exclusive message disabling the channels that shouldn't be played;

So, if I set my MT-32 to recognize channels 1-8, 10, instead of the default 2-9, 10, the driver will still mute channel 1 and I should not hear the PC speaker music data.  However, I wonder if this holds true for the early MT-32 drivers, which did not mute midi channels 11-16, which caused the CM-32P part of a CM-64/CM-500 to handle Adlib data. 

This is what makes these synths so cool. How many other synths from the late eighties can be made General MIDI instrument-compatible (other than *possibly* the Proteus 1)?

Actually, if you had two MT-32s, you could gain full GM compatibility!  Each MT-32 can divide the work, each using its 64 custom timbres for one-half of the GM sound map, one MT-32 using its 8 tone channels, the other using 7 tone channels and the rhythm channel.   Of course, you will need special software to remap on the fly midi channels 9, 11-16 to 2-8 on the second MT-32 and send the appropriate program change messages to the appropriate MT-32 and two independent midi output channels

[Cloudschatze]

For timbre data, it means extracting the data from the original control ROM, as opposed to requesting it from the unit with an RQ1 or RQD system exclusive message.

I hate to continue to be a bother, but I wonder how the default timbre settings can be stored in the control ROM.  Each timbre can take up 1-4 partials, and and each partial takes up 58 bytes to store its parameters.  If I added correctly, the 128 preset timbres use a total of 314 partials.  This equals 18,212 bytes.  For the 34 Rhythm timbres (4 of which are repeated one key lower), 42 partials are used.  If the Rhythm tibres work in the same way, that is another 2,436 bytes.  The 33 Rhythm tibres of the CM-32L use another 82 partials, for an additional 4,756 bytes, assuming the previous sentence is correct.  You also have to add another 15 bytes for the common parameter for each timbre, which equals 2,430 and 2,925 for the MT-32 and CM-32L, respectively.  I believe the MT-32 control rom is 64K, 65535 bytes.  So, just to contain the default timbres, the MT-32 requires 23,078 bytes to store the default timbres in its control ROM, 25,893 bytes for the CM-32L.  Is this correct?

The service notes state that the "operational program," "sound parameters," and "other sound related data" are stored in the Prog.Tone ROM(s) (1M in the 01 MT-32, and 256k X 2 in the 00 MT-32).

I'm not going to verify the math.

So, if I set my MT-32 to recognize channels 1-8, 10, instead of the default 2-9, 10, the driver will still mute channel 1 and I should not hear the PC speaker music data.  However, I wonder if this holds true for the early MT-32 drivers, which did not mute midi channels 11-16, which caused the CM-32P part of a CM-64/CM-500 to handle Adlib data.

It's not muting channel 1; it's simply not assigning that channel to any of the parts. The same holds true for the later driver, which sets the MIDI channels for parts 1 - 6 of the CM-32P/64 to "Off."

Actually, if you had two MT-32s, you could gain full GM compatibility!

Eh, not quite. You'll never have "full" GM compatibility.

[NewRisingSUn]

I wonder how the default timbre settings can be stored in the control ROM.

Every melodic preset uses 246 bytes, no matter how many partials are used. 128 melodic presets occupy 128*246 bytes=31488 bytes. Rhythm presets only use the first partial and thus only need 72 bytes, for a total of 2560 bytes. Preset instruments therefore occupy a total of 34048 bytes. Further required are 1000 or so bytes for the other default settings, and you still have 30k for program code. Verified with an 1.07 ROM image. Don't know about later units.

So, if I set my MT-32 to recognize channels 1-8, 10, instead of the default 2-9, 10, the driver will still mute channel 1 and I should not hear the PC speaker music data.

The driver will overwrite any channel settings you have made before. Only the driver mentioning the CM-64, though; the very early versions merely labeled "Roland MT-32 sound module" don't, of course.

Of course, you will need special software to remap on the fly

That's basically what iMuse is doing in later versions, expect with just one MT-32.

Prog.Tone ROM(s) (1M in the 01 MT-32, and 256k X 2 in the 00 MT-32).

I'm sure you misread something. That's the size of the PCM ROMs, not the control ROM. Or do you mean 1Mbits? Check that again.

[Cloudschatze]

Prog.Tone ROM(s) (1M in the 01 MT-32, and 256k X 2 in the 00 MT-32).

I'm sure you misread something. That's the size of the PCM ROMs, not the control ROM. Or do you mean 1Mbits? Check that again.

No, it says, "1M," but yes, bits.

[NewRisingSUn]

So it's 128kbyte for the new MT-32, then. Probably because the Demo Song data needs that much space. I wonder if it's in Standard MIDI File format?

The CM-32L also has a 512kbit (64kbyte) program ROM, suggesting that there was enough space from the 1.07 MT-32's allocation outlined above to accomodate the additional sound effects. (It also has another 512kbit ROM labeled "blank" in the service notes. What the hell?)

[Cloudschatze]

(It also has another 512kbit ROM labeled "blank" in the service notes. What the hell?)

Hehe. I think they have that listed in case you want to order a blank one.

[NewRisingSUn]

It's not part of the patch map, but determined by the channel bits in the SCI0 .snd resource header.

[Great Hierophant]

Every melodic preset uses 246 bytes, no matter how many partials are used. 128 melodic presets occupy 128*246 bytes=31488 bytes. Rhythm presets only use the first partial and thus only need 72 bytes, for a total of 2560 bytes.

You would think that ROM space being at a premium, Roland could have saved many bytes by only using as much space as the timbre had partials.  However, some Rhythm presets like the Open High Hats and the S & L Whistles used two or three partials, and a couple of CM-32L Rhythm timbres used four. 

[Alistair]

By the way, I'm not sure how pertinent this is, but:

For Conquests of Camelot it's:
Part 1 - MIDI channel 2
Part 2 - MIDI channel 3
Part 3 - MIDI channel 4
Part 4 - MIDI channel 5
Part 5 - MIDI channel 6
Part 6 - MIDI channel 7
Part 7 - MIDI channel 11
Part 8 - MIDI channel 11
Part R - MIDI channel 10

This may be an exception, anyway- CoC changes which channels are muted and which play with each MT-32 song file (most Camelot tracks had MT-32 on 2-5 or 2-6 and then Adlib channels on 6 or 7-9). So I can see why the D-10 map would be like that.

- Alistair