Chrisoft

This the follow up article of my first post on the SD-80. View it here.

It’s been one year and a half two years three years since I got my SD-80. A lot of stuff happened (including the great pandemic of COVID-19 and my escape from Wuhan). I’ve also discovered a lot more about the SD-80. Instead of updating the original post (which is already excessively long), I decided to start a new post instead.

The actual publish date of this post is 2022-06-30 because I have crippling procrastination.

My special thanks go to:

• Kalas, who contacted me for my original SD-80 post, without whom half of this article wouldn’t even exist.
• Discord user KR.Palto#7592, who also has a YouTube channel, for providing plenty of useful information and PCB shots of various Roland synth modules.

I’ve been procrastinating the release of this post for too long (almost 2 years by now). For this reason, the information I had on these modules may have updated half-way through the writing of this post. Therefore this post may contain self-contradicting statements. I’ll try to clear up any confusing parts. Feel free to reach to me if you find any, or just for any thoughts you have on this post. I would encourage anyone reading this post to get in touch with me if you have anything to discuss or find a mistake in this post. Every message will be greatly apprecitated. You can find ways to contact me in the “about” section of the home page.

“Official” Service Manual

The site where I got my other service manuals for Roland synths (none of which I really own) has been updated with a service manual for SD-80. I got one copy immediately once I knew about this (Special thanks go to Kalas for letting me know).

Most of the service manual goes as expected: the general format, most chips (I correctly identified all chips that has Roland marking on them somehow), the block diagram and testing mode. There’s really not that much information in this manual that is new to me. The schematics are extremely useful for modding and repairing though.

USB-PD Mod

WARNING: I’m a computer scientist (in its loosest sense), not an electrical engineer. Do not take any part of this section as advice. If you fried your equipment (I did!!) following this as an instruction, don’t blame it on me.

The 220V to 110V converter brick I have to carry around has been bugging me since the very first day I got my SD-80. Because the unit only consumes around 10 watts of power, I’ve always been dreaming of alternative ways to power it. When I first cracked my module open, I measured the power rails going out from the power supply unit: there is a ±15V pair, plus a +5V rail.

My top candidate was a solution based around USB-PD. I’ve seen people modding their ThinkPads to charge through USB Type-C on r/ThinkPad, so I thought that module plus some DC-DC converter circuitry will do the job. I also had a fallback plan, which is basically to use any switching mode power supply that accepts universal voltage has two output rails (one positive and one negative), and stick some additional regulator circuitry to generate the 5V output.

The USB-PD trigger module is actually very easy to come by nowadays, especially for someone in China. While others struggles to find these weird stuff on ebay and aliexpress, we just source them straight from taobao (which is essentially aliexpress for domestic users). There are even ready-to-use multi-rail voltage converter modules out there (they are either based around LM337/LM317, or TPS543x). Finally I picked the (seemingly) most popular PD trigger module people use to mod laptops from YZXstudio, and an adjustable voltage converter module based around TPS5430. The pictures below are from their sellers.

USB-PD trigger board

Adjustable VRM Module

I also bought some basic tools for soldering (Chinese knock-off of Quick 936A, lead-based solder and solder wick – I was too dumb to remember purchasing any flux) to make sure I can do the modding in my dorm.

I waited a few days for all packages to arrive. After that I tested every component I need and they worked just fine. It’s time to pull the trigger. I started with desoldering the AC input socket. That went decently smoothly. My confidence started to build up and proceeded to desolder the original SMPS module, which is a rectangular daughter board that has quite a few pins soldered on both sides of the board. Things went horribly wrong (particularly because I didn’t have any flux and the original lead-free solder refused to flow or blend with my leaded solder) and I started ripping tracks off the base board. Finally I decided it was an impossible task for me to desolder it without completely destroying both boards, so I simply drilled the pins out of the board. While the base board wasn’t totally destroyed, it was pretty close. I soldered wires directly to the components on the base board (because tracks on the other end have been ripped off). At this time my soldering job was just totally awful because I was pissed and it was super late into the night. Anyway, when I finally piecing everything together, it somehow worked.

Next it was time to put everything back into place. I had the idea of designing a 3d-printed holder for the USB Type-C extension cable that fills the hole for the original AC socket, however I couldn’t even afford a proper 2d-printing setup, let alone a 3d one. So I have to scrap that idea for now. None of the screw holes on the converter board can fit the holes on the chassis, so I just taped the module down. It was a complete mess inside my SD-80 now, but at least everything still worked (until a couple minutes later). I did mention that I had the wish to make custom acrylic chassis for my SD-80 some day in the future, hopefully I can get this mess fixed by then.

The USB-PD modded SD-80

(Accidentally) Circuit bent SD-80

I started messing around and decided to try to run the SD-80 without the ±15V rail. Everything except the front panel phones output and output 1 on the back panel worked just fine. This is not very surprising – all chips on the main board only takes <= 5V, and it makes sense to derivate all those voltages from the 5V rail. After a quick look at the service notes, I found that the ±15V rail is only used by the OpAmps in the final output stage of output 1, which is on the volume board.

And then something extremely stupid happened. Any proper electrical engineer will cringe hard. At this point I was getting cocky, and started randomly probing around with my multimeter on the volume board. I “accidentally” shorted the first two pins of the connector going from the main board into the volume board (pin 1 and pin 2 on CN7 of volume board). The output from the headphone jack immediately turns into complete garbage (severe distortions on low frequencies). The OpAmps chip on the volume board started getting ridiculously hot… crap! I still managed to fry something for an otherwise “perfect” modding project!

Of course this is undesirable. So I had to find a fix to this.

Fortunately, nothing on the main board seemed to be hurt. I can just bypass the volume control and get the correct output on output 1 using some jumper wires. So the fault is contained in the volume board. I’ve basically sent -15V straight into the base of two transistors, but measuring those transistors didn’t reveal anything wrong with them. So I had to assume I have fried the amp chip (NJM4565). I got a few replacements (NJM4580, compatible spec-wise) from taobao, and replaced the “faulty” NJM4565 (still without using flux). But the audio output is still messed up and the opamp chip still gets very hot after the replacement. I decided to give up for now, and look into the thing later. Meanwhile I just tucked some of the wires from CN6 into CN7 so that I can still get analog output from output 1 on the back panel.

My terrible SMD soldering

Recombined plug for volume board bypass

Recording Setup Update Part 1

Since I have always wanted to record my SD-80 through a digital link (even before frying the analog output), I have been keeping an eye on cheap digital recording solutions. Modern professional audio interfaces never come with digital input on budget models. Among the older interfaces, UA-25(EX) from Roland (EDIROL / Cakewalk) seems to be a reasonable choice. There are also a bunch of different models from various brands of the same era that have digital inputs. However these models are virtually impossible to get in China. Then some cheapo consumer grade stuff caught my attention – several relatively nameless brands have “sound cards” for home theater uses that have digital I/O. Those are priced at roughly 200~300 Chinese yuan. Among those I found a more widely recognized brand called Terratec. They have PCI-e and USB sound cards that comes with digital I/O and are available for purchase in China. Price are on the higher end (300+ CNY), however still way cheaper than the cheapest professional audio interface that doesn’t have digital I/O (those start from ~800 CNY). Plus these models seem to have a reasonable Linux user base, so I got their Aureon 7.1 USB.

This thing feels extremely cheap on first sight, weights close to nothing, and is made entirely out of plastic. It comes with an extremely thin S/PDIF fiber optical cable which looks so fragile that a single touch may break it. It does work out of the box. ALSA recognizes it as “Aureon 7.1 USB” without further clue about the chip it uses, however the Windows driver is more telling. Its control panel associates the chip with a Taiwanese company called Cmedia, and the kernel driver is named cm106.sys. Upon further investigation this thing is likely to be based on their CM106 chip (which is an ancient solution from 2003), or its pin-compatible successor CM6206. I don’t have interest in disassembling it right now (update: confirmed by a teardown later. It’s indeed based around the CM6206), but either way it’s a cheap consumer grade solution.

SD-80’s digital output is fixed at 44100 Hz sample rate. So the sound card must also record at 44100 Hz to make a correct recording (unless it has internal resampling). This is easily doable under Windows (just select the appropriate sampling rate in the device properties dialog). It’s also reasonably easy with Jack, where you can just start the server on that specific device with the correct sampling rate. But this is not that easy to achieve for pulseaudio. By default, recent versions of pulseaudio auto detects cards with the module-udev-detect module, which doesn’t allow setting a different sample rate for a single sound card. Setting alternate-sample-rate doesn’t work either because this card supports digital signals at 48000Hz which in my case is the value for default-sample-rate, and therefore would not fallback to alternate-sample-rate. I had to write a small function to fix this:

spdif_samplerate()
{
    pacmd unload-module `pacmd list-modules | grep -B 2 Aureon_7 | awk '/index:/ {print $2}'`
    pacmd load-module module-alsa-card device_id=`awk '/Aureon 7\.1 USB$/{print $1}' /proc/asound/cards` name="usb-0ccd_Aureon_7.1_USB-00" card_name="alsa_card.usb-0ccd_Aureon_7.1_USB-00" namereg_fail=false tsched=yes fixed_latency_range=no ignore_dB=no deferred_volume=yes use_ucm=yes avoid_resampling=no rate=44100
}

Using a cheap consumer grade card does come with consequences. The recording seems to have a small DC bias – it’s not real DC though, the offset changes from time to time. When the input signal goes silent, the offset might differ from the offset when the signal was silent last time. [2] For this reason, I always add a high-pass filter when using the material recorded by this sound card. With the HPF applied, this sound card does produce clearer digital recording than my Scarlett Solo with very cheap cables.

There’s no ASIO driver for this card either (Aureon 7.1 PCIe does have ASIO driver, but I can’t install that card on my laptop), which means I have to either use Steinberg’s generic ASIO driver, or ASIO4ALL, both of which are… kind of trash, but still usable. The card doesn’t have a bad latency issue though: it’s obviously way worse than the Scarlett, but still tolerable.

So that’s my current recording setup. I’m currently OK with it. However I’m not going to stick with it forever. I’ll upgrade to a UA-25(EX), or better yet, an SD-90 because that way I can use its ASIO output directly, plus I’ll be able to chain my SD-80 to it and use both at the same time.

Recording Setup Update Part 2

(This part is written Q4 2021)

Yes I did upgrade to a UA-25 (non-EX). I got mine for about $60 (after a long struggle against eBay’s virtually non-existent customer service to lift a stupid suspension on my account).

Gentoo Linux handles this new interface without any problem. The troublesome part is Windows (again). Just like the SD-80, Roland didn’t release any Windows 10 driver for the UA-25. The trick I used to make their SD-80 Windows 8/8.1 driver install on Windows 10 worked fine, and the driver installed correctly. But things quickly went down hill. Whenever I open an application that uses ASIO, the driver freaks out and causes audio dropouts like crazy. This glitch makes the driver basically unusable.

I tried drivers for different Windows versions. Nothing changed. When I was desperate and searching around the web, I discovered that UA-25EX has an official Windows 10 driver. UA-25EX is virtually the same as UA-25 except it comes with an improved limiter section which I assume has largely nothing to do with the driver. So I decided to try some “mad hax”.

Windows driver for UA-25EX is only available from Microsoft as a Windows update package. Roland says if you have a UA-25EX, the package will automatically install itself once you plug it in. But I don’t have a UA-25EX: I only have a UA-25. So I had to go to the Windows Update Catalog, looked for the driver package there, and download the build for my computer (which turned out to be much harder than it needs to be, but I won’t go deeper into that here). I extracted the package, and modified the USB product ID the driver is designed for in the INF file:

%DriverDeviceDesc%=DriverInstall, USB\VID_0582&PID_00E6 ; UA-25EX

Just change PID_00E6 to PID_0074 (and also the comment if you wish). AND IT FRICKING INSTALLED. ASIO also worked perfectly. (Insert a thousand-word essay trashing Roland’s bad practice here.)

So did the upgrade work? Nope. The DC bias is still there. Now it’s more likely that the DC bias is from the SD-80 itself. Also another very telling clue is that when the sound generator inside the SD-80 is reset, the DC bias immediately goes away. I did some additional research on the Internet and discovered people have theorized that the DC bias is from the effect processor. They are having a similar problem with their XV-5080 and XV-5050 as well, both of which have the same synth engine as the SD-80. By replicating their experiments and getting the same result, I personally conclude that the DC bias comes from the amp / gain / filter section of the integrated effects processor. So I guess I’ll have to keep using high-pass filters on the output for now.

So the only upgrade is that now I can record S/PDIF signal with native ASIO. Besides that, it’s actually a downgrade: Output from the computer will be muted if the digital input of the UA-25 is enabled. This forced me to keep using the analog input for monitoring.

Recording Setup Update Part 3, 4, 5…

Yes I did upgrade. (again!!)

I saw a UA-101 in a listing for $80. I bought it. Then there was a whole saga which ended in me getting two of them for the price of one. And then I saw a SD-90 for $120… you know what happened.

This is getting too long to write in detail here. I’ll give detailed information on my current recording setup in a new post, if I care to write it at all.

Rompler Preservation

Kalas was extremely keen on preserving the sounds of SD-90/80 during our communications. I have the intention to keep these legendary Roland sounds around long into the future as well. We discussed the following possibilities. Note that due to the locked-down nature of SD-90/80, we referred to them mostly as “Romplers”, but these methods listed below apply to those expandable models as well, especially considering they are nothing but romplers that you can add more ROMs to, and the architecture of Roland’s PCM synth.

In this section I’ll start using the word “SD-90” and “SD-80” interchangeably, and by saying “SD-90”, I’m actually referring to the synthesizer module built into it. If Roland was being honest when they were saying “the newly developed multitimbral MIDI sound module, as built into the well-received SD-90” when they were introducing the SD-80 [3], it should be safe to assume they are virtually the same thing. I know this is kind of sloppy. If you want to read more on this, checkout the “More on SD-80 vs SD-90 vs SD-20” section.

Emulation

This method was brought up by Kalas. Indeed there are a couple of sound modules / synthesizers that has been emulated with reasonable success. Munt has an amazing emulation of Roland’s LA synthesis found in the MT-32 or D-50. [4] Yamaha’s FM synthesis chips have been reverse engineered from inside out: there are implementations on FPGA, multiple nearly perfect software implementations, and other bizarre stuff. MAME has emulation for multiple MU-series models, plus work has been put into making an emulated SC-55 in MAME.

However, I personally don’t think emulation is the way to go for SD-90/80. The success (or lack thereof) of these emulated models does have their reasons:

• Emulation of Yamaha’s FM chips is a success because those chips are available to third-party sound card makers, and therefore have public datasheets that contains critical information for emulating the chip, which includes register mapping, and the detailed architecture of the FM synthesizer. This drastically decreased the amount of reverse engineering required to get a perfect emulated implementation. Roland has never made their synthesizer chips available to third-party vendors, and therefore it’s impossible to take advantage of public datasheets.
• Emulation of several early gaming consoles’ sound system has been successful because
  • They are relatively sample.
  • Similar to Yamaha’s FM chips, programmers can also directly interface with them. Therefore their programming manuals have detailed description on how sound generation works in the chips. SD-90/80’s synthesizer chip XV meets neither of these two criteria.
• Most emulated sound modules in MAME have been a failure in terms of real-world usability. The emulated MU-series either freezes, produces no sound at all, or makes loud unexpected noise when playing the demo track. The SC-55 emulation barely works – they only got the CPU working and running its dumped control ROM. Please don’t get me wrong: the fact that some emulated MU model could make any sound is almost a miracle for me, and definitely a huge achievement despite the far-from-ideal results it currently has, as Yamaha’s sample based synth chips (GEW/SWP stuff) are no easy nut to crack. This approach is highly unlikely to work for the SD-90/80 because unlike gaming consoles, getting the CPU to run its system code doesn’t mean much for synthesizer emulation. It’s the emulation of the actual synth/DSP chip that matters. And the XV chip found in SD-90/80 is a monstrosity compared to the early SWP chip in the MU-series. For this reason, I find a pure emulation based solution difficult to implement for SD-90/80.
• Munt is successful because instead of an instruction-to-instruction emulation, it’s more like a software reimplementation of the LA synth. It doesn’t try to run the control ROM on an emulated Intel 8098 CPU, but instead only use it for determining some characteristics of the software implementation of the LA synth. This approach makes the most sense when trying to recreate SD-90/80 in software form, but still definitely require tons of reverse engineering (either blackbox or whitebox).

For these reasons, I don’t think an OPL3-level emulation of SD-90/80 is possible [5]. However, I will discuss an approach that resembles Munt’s in the Dumping and Deciphering section.

Sampling the Rompler

Many people have attempted to sample the SD-90. We already have the (in)famous THFont from forever ago that contains some samples from the SD-90, plus these efforts to create a complete set of sampled instruments from the SD-90. However, these folks aren’t doing it in the most efficient way IMHO. Since the SD-90/80 is extremely editable, one can craft presets ideal for raw sample extraction (no filters, no LFO, just a plain tone with a constant amplitude envelope). Since many preset instruments in the SD-90/80 consist of multiple layers using different samples, instead of sampling the patches, one can sample every individual waveform and layer the samples in a way similar to the original presets to make close imitations of SD-90/80 instruments. If done properly under ideal conditions, the resulting sample library should be around the same size of SD-90/80’s sample ROM, but decompressed (my guess is ~64 MiB [6]).

If you’re only going to use the vanilla SD patches without any sort of modification (including filter response, envelope, and effect parameters), those existing samples will work just fine and they are probably the most accurate out there if recorded properly. Of course, the “efficient” approach of sampling sacrifices some level of that accuracy (due to a different engine being used for playing back the samples). But in exchange you get the highest level of freedom to recombine the raw samples into custom patches including tweaking all possible parameters and effects available in the synth engine of your choice (which is a huge plus for me personally, as I love to create whacky patches).

One problem for extracting the samples is that, a single waveform in the SD-80 may contain different samples assigned for different key ranges. This is often called a “multisample” by some sources. The way the samples are mapped to the keys must be figured out before actually sampling them. I have written a small(ish) python script to do exactly that. It records the SD-80 playing two different keys at the same pitch one after another, and compare them by calculating the correlation. If the correlation is lower than a threshold, the two keys use different samples. This approach works reasonably well for most samples, but for a few analog synth samples, it works poorly. For those samples, I had to resort to relying on the human ear (DTW, dynamic time warping, is also used sometimes, but it usually has poor results for these samples as well). Also the XV engine have some weird quirks near the keys C7-D8 (96-110). The actual waveform produced within that range varies very slightly from time to time. This is possibly due to the effect of aliasing becoming prominent for these high-pitched notes. I have already figured out key-sample mapping for all multisamples (they are not guaranteed to be correct, due to reasons mentioned above).

Another problem is looping. Roland uses sample looping extensively in their PCM synths. It’s basically their secret sauce to squeeze thousands of instruments into a unit with only tens of megabytes of samples. Sample loop points can also be computed using cross-correlation. But is nowhere near perfect. Of course it can be done manually, but that would be a tedious task.

No actual recording of the raw samples have been done by me yet.

I have also dumped the instrument configuration for all preset instruments and rhythm sets as part of my SD-80 dumping project (for SD-80’s native mode only. I’m not sure whether this is doable for its GS/XGLite instruments without a lot of reverse engineering, but nobody cares about those anyway). For now, it can be used to recreate parameter-accurate SD-80 patches in Roland’s SRX/Zenology plugins. However it’s not yet in a very human-readable form (either raw binary registers dump or decimal values with field names).

Once the samples are there, one can easily piece them together within the sample playback engine of their choice, be it HALion, KONTAKT, or even just soundfont synthesizers. Sure the feature set of each sample-based synth engine is not exactly the same, but I think decent results could be achieved for most instruments.

Dumping and Deciphering

The wave ROM in the SD-80 is a standard part despite the custom Roland engravement on it [7]. This is expected because Roland has been using standard mask ROM parts from various manufacturers for the wave ROM. This means the content of SD-80’s wave ROM can be easily dumped.

This might be shocking for some of the readers, but Roland does compress their samples. This is evident from the specification of XV-5080 “Wave memory: 64MB (16-bit linear format)” while the XV-5080 only has 32 MiB wave ROM. The compression, previously unknown to me, has been identified to be a variant of the differential pulse-code modulation (DPCM) called FCE-DPCM by some amazing person. The same person seemed also figured out the structure of the wave ROM used by sample-based synthesizers from Roland of that general era. Unfortunately, I wasn’t able to find the article on the technical details of the compression method at the time of writing. Anyway, hats off to Edward of dtech.lv!

I will surely make a dump of the wave ROMs of my SD-80. However, I want to do it in an nondestructive manner – I don’t want to get a ROM dump and an unusable SD-80 (or end up with no valid ROM dump and an unusable SD-80). Since I have proved my SMT soldering job is terrible and shall never be in the vicinity of a SMT board holding a soldering iron or hot air gun, I might try some clipping the chip instead. I’m considering to try this clip from 360-clip. It claims to be applicable to any 48-pin TSOP chips. If that’s true, with the help of this clip and a Raspberry Pi [8], I can suck that juicy content out of the wave ROM chips of the SD-80.

Once we have the ROM dump, we can start trying to figure out its structure. If we somehow managed to do that, we would be able to feed the decompressed samples together with the already dumped patch parameters to some existing or new, custom sample-based software synthesizer, and achieve decent results mimicking the SD-90/80. Patches that make use of MFX would certainly be a pain to deal with. However one can always simulate MFX with external DAW effects. To hear the difference MFX makes for various preset patches that use it, see the “What role does MFX play?” section.

I believe this approach is very similar to that one used by Munt (although I only read a small part of Munt’s code base, and I didn’t read anything about their reverse engineering approach). The SH3 CPU plays a relatively minor part in the tone generation of SD-80. Instead, we should focus on replicating the sounds of the XV engine. Also, an logic-level reverse engineering of the XV chip doesn’t seem reasonable because it’s such a huge and complex chip (or rather, a huge gate array). Just save the hassle, treat it like a blackbox and try to reproduce its output using a software implementation should be able to produce acceptable result on its own.

Extra rambling about the ROM chip

In the part number of μPD23C128040ALGY-***-MJH/MKH, the *** part is the ROM code. When a mask ROM chip is commissioned, the customer (Roland in this case) needs to submit the desired ROM content and their choice for various other options (in case of μPD23C128040ALGY, they can choose how the logic level on a certain pin controls the outputs). The manufacturer then arrange the mask according to this information and assigns a ROM code to this specific mask [9]. Therefore, for two chips of the same type, if they have the same ROM code, their contents should be identical. This way we can guess with fair amount of certainty that the XV-3080, XV-5080 and XV-5050 have identical wave ROM contents (they all use μPD23C128040ALGY-849-MJH and μPD23C128040ALGY-850-MJH).

Among the chips with Roland markings in the SD-80, the XV chip and 8-bit MCU with Roland-programmed ROM has other markings that matches Roland’s internal part numbers (the numbers with a prefix R, like R01455956 and R02902867), and followed by a indicative part number of the actual chip (137 and RA08-503). However, none of these features matches on the wave ROM chips. The wave ROM chips has internal part number R02678601 and R02678612, while the numbers on the service manual are 03010612 and 03010623 respectively. The indicative part also doesn’t match either: the chips in my unit have 23C128L-529J and 23C128L-535K. While the J/K variant and the 23C128L part does match, what I presumed is the ROM code doesn’t (529 vs 525 on IC28, 535 vs 526 on IC29). What does this mean? I don’t really know. My SD-80 is built relatively late into production (date code on the main board is 2004-08-27, date on the service manual is May 2002 – when the SD-80 was initially released). Maybe Roland did revise the wave ROM content. If that’s the case, it would be interesting to find one with the original ROMs and compare them. I wouldn’t expect there to be any significant differences, though.

SD-20 MIDI File Converter

This extremely intriguing piece of software is brought up by Kalas during our communications. At the time of writing, this application can be still found here. The installer can only proceed if an SD-20 is detected. This can be easily circumvented by using a InstallSheld extractor. The converter does try to access a registry key HKLM\Software\Wow6432Node\Edirol\SD-20 MIDI File Converter\BaseDataFile, which should be set to a string pointing to the url of its param.dat file. However, even with this key set, the converter still refuse to do anything, saying it failed to initialize. By the way even with an SD-20 connected to the computer via USB, the converter still refuses to start on Windows 10.

However, this kind of nonsense is not going to stop me. I quickly found cracks floating around on the Internet. This converter is extremely simplistic: you pick the midi file to convert, it spits the wav file into the same folder. Here are some quick samples.

Used instruments: St.Strings, St.Timpani, St.Harp, St.Fr Horns, Flute vib, St.Tubular, St.Harp, St.Xylophone, St.Music Box, St.Room, Bassoon vib, SpaceVoice 3, Atmosphere 3, Ice Rain 3, PanFlute vib, Bird Tweet, Seashore, Sweep Pad 3, Rockabilly, St.Kalimba, Piccolo vib, Steel Drums, Tuba vib, Romantic Tp, St.Banjo, Trombone vib, JazzClarinet, Gunshot, Clavi Bass 3, St.Brass, Dist.Gt 2, St.Orc Hit, Jazz Organ 2, PhaseFrtless, Solo Vox 3, Reed Romance, Ice Rain 2, St.Power, Oct.JP Saw, SH-2 Lead, Jazz Slap, OverdriveGt2, Applause.

Reed Romance and SH-2 Lead are from the special 2 set, therefore cannot be used by the SD-20 MIDI File Converter. They are substituted by Violin 2 vib and Warm SynHorn automatically. A single SD-80 system exclusive DT1 message is used to change the patch volume of SH-2 Lead.

Used instruments: Enh.Nylon o, Ocarina vib, St.Slow Str2, PhaseFrtless, Celtic Ens, St.Standard, Soft60’Organ, Pre Bass, St.BritePno.

St.BritePno is a custom patch. It’s selected using system exclusive messages generated by SD-80’s bulk dump feature. Enh.Nylon o, Celtic Ens, Pre Bass are not available in the SD-20 Converter.

The output from the converter is significantly louder than SD-80’s digital output. I normalized all recordings before uploading them. Despite the lack of a lot of features and patches, the converter actually sounded exceptionally good, and exceeded my expectation by quite a large margin.

The converter is not a software implementation of SD-20’s internals. There’s misinformation out there claiming so, but that’s simply not the case. Roland explicitly disclosed this in the readme file of the converter.

FrankenTTS-1

Something smells fishy instantly when I got this converter. That file name “param.dat” looks really familiar. If you have used any of Roland’s HQ software synthesizer products from the early 2000s [10], you might feel the same. They all use this file to store their samples and patch data.

One natural thing to do is to replace the param.dat file of these plugins with the one supplied with the converter. The result are as follows:

• HQ-OR/HQ-QT refuses to load at all after the swap.
• HQ-GM2 loads correctly. Instrument names changes to the names from SD-20’s Classical set (for example, 1:0 changes from Piano 1 st. to Piano 1w). Only instruments from the Classical set are available. No NRPN messages can change the instrument set. The sound is pretty much identical to that from the converter.
• GrooveSynth (P5antom) also loads correctly. Besides all instruments from the Classical set, a couple of instruments from the Contemporary set and Solo set are also available, but there’s no obvious pattern there. All rhythm sets are available in the Franken-GrooveSynth.

This reveals that the synthesizer engine is identical to that used by these HQ software synthesizers, proving the claim that this converter is a software implementation of SD-20 wrong again.

There’s not much information about the structure of this “param.dat” file online, nor could I figure it out myself (I’m not a huge fan of doing such work). However this interchangeablility is somewhat delighting.

Other observations

The executable of the converter is a mere ~500KiB and doesn’t seem to use an executable packer. This suggests the “HQ” engine couldn’t be super complex.

The executable contains references to “Automation”, “User Rhythm” and such. Apparently they still left some code from the plugin version of the HQ engine in this converter.

I think I found the entry to the function where param.dat is loaded (0x004228e0). No idea where to go from there though.

So… is this it?

Nah, we should not depend on a piece of proprietary junk for the preservation of anything.

Maybe some wizards could find a way to hack the plugins and make all instruments available in TTS-1 or something. But that doesn’t really work as a way to preserve the synth if the binary code it depends on could stop working at an arbitrary point of time in the future, does it?

Roland Cloud

Roland has been pushing their subscription service “Roland Cloud” since 2018. When it first came out there was no plugin of my interest. The deal breaker for me back then was there was no permanent licensing option. If you know me, I’m strongly opposed to the subscription model used for software products.

Starting from May 2020 though, Roland started offering “lifetime keys”, which now puts this service within my radar. I took the ultimate tier trial and installed every piece of plugin replicating SRX boards and the XV-5080, as well as the then-new “Zenology” synth. I’ve got mixed results.

The software aspect is okay. It’s much better than SoundCanvas VA I’ve used years ago, which has glitchy TVA and TVF and was never fixed. The user interface scales perfectly on high DPI screens. Editing experience of the SRX/XV plugins is basically the same as the editors for later Roland PCM synths (such as the SonicCell and the Integra-7) – that is, much better than the original XV or SD-80 editor. These plugins still have terrible performance as most previous Roland software synths do (each instance needs plenty of processing power – if you use a computer that predates the release of these plugins, the performance will probably suffer).

The sound is … fine? Didn’t give me the same astonishment when I heard a real XV-5080 on YouTube though (I thought “no way this thing only has 32 MiB of sample content!”). For most patches, they sound “close enough” to an actual XV-5080, despite a handful of caveats. The synth engine do behave nearly identical to actual XV-based synths, at least according to my tests. The XV-5080 plugin is especially underwhelming, considering the original XV-5080 is expandable and can also load external samples. If only the XV-5080 plugin could load samples and patches from other SRX plugins installed, it would have been a lot better (although this is solved by Zenology, it has its own issues). The MFX uses a different set of effect types from the original XV-5080 and SD-80: they are modeled after synths after the Fantom-S era). However I’d say the effects bearing the same name as XV effects do sound largely the same.

The executables contain a resource folder named “WROM”, and it contains the wave ROMs used by the plugins. They are all exactly 32 MiB. The wave ROM files contains a similar 32-byte header to dumps of actual wave ROM of earlier Roland PCM synths (see the JD-800 wave ROM dump from Edward of dtech.lv).

I do have some major complaints though. Each executable contains a copy of the wave ROMs. If you choose to install all plugin formats, that will install 4 copy of exactly the same wave ROM on your computer. Also it’s impossible to combine the sounds of different SRX boards. Most samples originated from Spectrasonics are missing from the SRX plugins but are reincluded in the EXZ expansions which can be used in Zenology, indicating a copyright dispute between the two companies that was resolved later [11]. These problems can be partially solved if you use the newer Zenology plugin instead. But Zenology is riddled with its own issues. It uses a nearly entirely new set of MFX (identical to the MFX from their 2019 Fantom-6/7/8 workstations and other “ZEN-CORE” based products), and completely lacks reverb effects. Effects that have the same name in Zenology and XV-based synths doesn’t necessarily behave the same. And Zenology still can’t load samples from different sample groups to left and right channels of a single voice. I know it’s a thing in the original XV, but since it’s a software reimplementation, they don’t have to stick to the same restrictions do they? Also, why are all these plugins monotimbral? If your answer is “just use multiple instances”, I would remind you that these are Roland software synths, and they don’t perform well if you add multiple to your virtual rack…

Recreating patches of the SD-80 using these plugins does seem to be possible, and there are already plenty of people doing that. See the section “SD-80’s sound content” for details. However it does still rely on proprietary Roland software products (which, if they want to, can cease the support at any time), requires pricy licenses, and on top of all that, a crappy authenticating system.

A History lesson from someone who barely knows anything about it

AKA a short history of Roland’s sample-based synths from someone who has used almost none of them.

Below is a comparison chart of selected sample-based synths from Roland using information available from their manuals (mostly sysex address mapping in the MIDI implementation) and service manuals. In a few occasions sources from the Internet are used as well.

The following section summarizes generation-over-generation improvements of the synth engine noticed by me reading the manuals. There is a little bit of technical assessment of the chips, however most of it is not based on analysis of the actual chip, instead it’s based on analysis of the most capable synth model using that chip. Some of the features might be added with newer version of system software (such as the multisampling feature on XV-based synths mentioned below) rather than improvements on the actual synth chip. It’s in no way, shape or form complete. A lot of synthesizer keyboard models are not listed. It could be way too technical for some readers. If that’s the case, feel free to skip this section.

LA

Not strictly a PCM synth. Only uses PCM for the attack phase of the sound. Already showing Roland’s base designs for later PCM synths: 4 “partials” (this term is from 80s Roland samplers, and was referred to as either voices or tones in later products) for each patch. Each partial has its “timbre”, which consists of a WG (“wave generator”), 5-stage envelope generators for filters and amplifiers (which in later PCM synths were reduced to 4-stage), and a single LFO for mod wheel. Filters are always low-pass. Poor panning resolution (15 steps instead of GM’s 128). Rhythm patches reference to individual “timbres” on each key. Usually paired with external reverb and chorus processing chips. Up to 32 polyphony.

Used in MT-32, CM-64, CM-32L, D-110 (as MB87136A “LA32”, QFP), and D-50 (as MB87136, PGA).

Due to the popularity of MT-32, which is supported by a whole bunch of DOS games, emulation of this engine is pretty well-developed already (see the aforementioned Munt project).

(Unnamed synth engine in U-110)

An early (late-1980s) incarnation of Roland’s PCM only synth. No filters at all. Amp env reduced to 3 stages (?). The synth structure looks more closely related to that of LA rather than later Roland PCM synths. 31 polyphony. The synth consists of two chips: MB87419 and MB87420. The former seems to act as a controller, while the latter does the actual sound generation. There’s an additional chip to handle output selection. Also relies on external chips for effects.

Interestingly, MAME has a partial implementation of this synth engine (src/devices/sound/rolandpcm.cpp).

Found in U-110, U-220, CM-32P and various R-8 variants.

EP

Early-1990s PCM synth. Has filters but requires an external TVF chip.

The models using this engine seems to have roughly the same feature set as GP-based models. However they lack a lot of controls for rhythm patches. Some models come with a much more powerful effects engine (which is external to the EP chip).

Used in HP-3700/2700 (as MB87731), and JD-800/990 (as MB87731A).

GP

Uses 4-stage envelope generators for filter and amplitude. Has two filter modes (LPF and HPF). Individual tones can be delayed after the note is triggered. Each tone has 2 independent LFOs. Has a rudimentary modulation matrix (with fixed modulation sources). Reverb and chorus effects are integrated in the chip. Most parameters now accepts values from 0 to 127 (rather than 0 to 100 in LA-based units). Has FxM (frequency modulation) capability. More parameters can be modulated by key follow or velocity, which now also supports velocity curves and sensitivity offsets. Up to 28 polyphony on GP4 (24 on the original GP).

The original GP (TC24SC201AF-002) is used in JV-80 and SC-55.

A later variant “GP4” (TC6116AF) is used in JV-880, SC-55mkII and MC-303. It contains an additional gate array as LCD controller and handles extra IO.

XP

This iteration has a lot of variants.

Original XP

Two additional filter modes (BPF and PKG). Modulation matrix has partially configurable modulation sources. Introduced random panning and alternate panning. Key ranges of tones can be limited. Voice priority (which note to steal when a new note is played if polyphony is maxed) can be adjusted. Has integrated effects processor with 40 available effect types. Up to 64 polyphony. This chip seems to have the facilities for pairing two of them together, but none of the production rack units make use of this feature as far as I know. 24-bit wave address bus for a maximum of 16777216 words (=32 MiB) addressable wave ROM per chip.

Used in JV-1080 (as MBCS30109B), and SC-88 (as MBCS30109).

XP2

Seems to be a drop-in replacement of the original XP.

Used in production units of XP-80 (designed with the original XP) and SC-88VL (both as MB87B105PF-G or RHR-2342).

XP3

Seems pin-compatible with the original XP.

Used in JV-2080, SC-88Pro, and JX-305 (as TC170C200AF-005 or RA01-005).

XP6

Tones can have different samples on each stereo channel. Two extra filter modes (LPF2 and LPF3). Fully configurable modulation matrix. 63 internal effect types. Up to 64 polyphony. Actual models with two of these chips exist (XV-3080 and SC-8850).

Used in XV-3080, JV-1010, XV-88, SC-8850, SC-8820 and SC-D70 (as TC203C180AF-002 or RA09-002). XV-88, XV-3080 and SC-8850 use a pair of XP6.

XP7

Cut-down variant used in low cost models. Only the 40 “classical” JV/XP effect types are present. All XP chips before XP7 work at a 32 kHz output sampling rate (24.576 MHz clock input, 768 clock cycles per output sample, or 12 clock cycles per voice). XP7 is also capable of operating at 44.1 kHz with a 33.868 MHz clock input (found in the SD-20 and DR-880).

Used in XV-2020, SD-20, DR-880, and E-09 (as TC203C180AF-003 or RA0C-003).

XV

Mostly the same as XP6, but with COSM effects (guitar/bass amplifiers, speaker & microphone emulation) and two additional effect slots. 90 internal effect types. 3 insertion effect slots (40 of the 90 effect types takes all 3 slots if only one chip is used). Up to 64 polyphony. Has an additional memory controller for sample RAM, enabling dynamic sampling. Can be paired to double the maximum polyphony and improve effects DSP power. 25-bit wave address bus for a maximum of 33554432 words (=64 MiB) addressable wave ROM per chip (all XPs have a 24-bit wave address bus).

Used in XV-5080, XV-5050, SD-90, SD-80, Fantom, Fantom S/S88, MV-8800, and MC-909 (as TC223C660CF-503 or RA08-503). XV-5080, SD-90 and SD-80 use a pair of XV.

XV-5080 seems unique among these models as it has a (software) switch between two master clocks for the XV chip that allows for switching between 44.1 kHz and 48 kHz output. The XV engine in all other models listed above outputs at 44.1 kHz. Twice efficient compared to the XP series, the XV chip needs 6 clock cycles to process each voice, which translate to a input clock of 16.9344 MHz (44.1 kHz output) or 18.432 MHz (48 kHz output).

Earlier models with sampling capability using this chip doesn’t have proper external multisample support until Fantom S/S88, suggesting the multisample support is added with system firmware rather modifications to the synth engine.

WX

Capability wise, WX seems to be the equivalent of dual XV with the external effects chip used in Fantom S/S88 (TC223C080AF-101, RA0A-101) integrated. 78 internal effect types plus mastering + input effects. Also added proper multisample support for external samples, which the XV-5080 lacks. [15] Up to 128 polyphony. 25-bit wave address bus for a maximum of 33554432 words (=64 MiB) addressable wave ROM per chip. Wave RAM on general data bus instead of wave bus. WX chip is only seen operating at a 44.1 kHz output, and uses a input clock of 16.9344 MHz (3 clock cycles per voice).

Found in the Fantom-X series and Fantom-G series, as well as MC-808. (SonicCell and SD-50 are also likely equipped with this chip, but I’m not 100% sure.)

Beyond WX

From this point on the service manuals from Roland have become less useful. They stopped listing the ICs in their parts list. However the block diagram and schematics remain.

Roland introduced the so-called “SuperNATURAL” sounds with their Fantom-G series, together with its new expansion board format (ARX). These boards has a CPU built on it (the same SSC7 CPU used in Integra-7). The CPU is connected to a set of RAM named “Effects RAM” in Roland service manuals. Fantom-G by itself doesn’t appear to have any “SuperNATURAL” sounds preloaded, and these new sounds clearly breaks some of the limitations of the old synth engines. This leads to my suspicion that the ARX boards have self-contained synth engines on board, and the new “SuperNATURAL” engine is either software based, or the SSC7 chip has some sort of extra bits that doesn’t belong to the CPU (that is, an integrated ASIC DSP block). The SSC/SSC7 chip is seen on all ARX boards, as well as the Integra-7.

Along with this new CPU thing, there are new effect processors/DSPs: WSP and ESC2. WSP is found in a few relatively earlier (2009-ish) models, while ESC2 is appears in almost all post 2010 Roland synths (Integra-7, probably all Boutique models, and the latest Fantom-6/7/8 series). A single ESC2 chip is able to provide 16 individual effect slots in the Integra-7. However sometimes two of these chips can be seen in some of the Boutique units. It also has a JTAG interface, and handles USB connectivity in the Integra-7, leading to the suspicion that it also has a microcontroller built-in.

Role played by the CPU in sound generation

When I started writing this post, my thoughts were the vast majority of the synth functionality is contained in the synth chip. In other words, the synth chip provides a very high level of abstraction, and the CPU only needs to pass processed voice events to the synth chip. In retrospect this is not plausible, due to the following facts:

• Models with the same chips sometimes have significant feature disparity (Fantom-S with external multisamples which is not found on any other XV-based models).
• Only the CPU has direct access to the memory that stores patch parameters.
• There’s no reason for such a powererful CPU in some low-end models.

My current hypothesis is the CPU handles:

• control matrix mapping, preprocessing of some parameters (velocity curves, for example)
• voice (individual tone) allocation and parameter specification
• effect and output routing configuration (actual routing happens in the synth chip/DSP obviously)
• certain LFOs (maybe? [16]). Envelopes (even less likely).

This means the synth chip could contain basic blocks for various subsystems (sample playback, modulation, effect processing, etc). Routing among these blocks is controlled by the CPU. If you are somewhat familiar with hardware accelerated rasterization in computer graphics, you may find this architecture has resemblance to the old fixed function graphics pipeline.

Other Curious Stuff

SD-80 is an XV-5080 …

… locked into performance mode and with samples cherry-picked by Roland?

Indeed, the address mapping [17] for the SD-80 is almost fully compatible with that of XV-5080. Even a lot of parameters that make no sense for the SD-80 are preserved: SD-80 has a parameter to select which wave expansion board to use, wave groups (which the SD-80 only has one), as well as parameters for “multi-partial” patches, which on the XV-5080 is a way to put together patches that use samples loaded into the RAM. Only the first one has its description changed to “reserved” in the documentation. The SD-80 doesn’t have any wave expansion board slots hidden inside, nor does it have support for external sample loading.

Of course from the form factor side of things, the SD-80 looks more like a cut-down version of XV-5050 which is a full 1U rack unit while the SD-80 has a 3/4 rack design. However the SD-80 does retain XV-5080’s 128 polyphony and dual XV guts.

What is called “Performance” in XV-5080’s address map is called “Multitimbre” in SD-80’s address map. They have the exact same content inside (well, not really exact – SD-80 has quite a few extra parameters in the “Multitimbre Common” section, mainly to expose some GM2 parameters and parameters that earlier SoundCanvases had in their address maps). On the XV-5080, you can save the performance to one of its 64 performance memory slots. Configuration of all 32 parts of the synthesizer is restored from the save slot when a performance is loaded. Just like the XV-5080, the SD-80 has a name assigned to its “Multitimbre”, which is set to “Native Mode” upon entering its native mode. But there are no memory slots for “multitimbres” in the SD-80, nor is the name of multitimbre shown anywhere (either on the LCD screen, or in the SD-80 Editor), rendering this name useless. This name is not read-only. You can change it as you wish using system exclusive messages, and is preserved until the next native mode reset message is received.

Since the SD-80 is straight up the same when compared to the XV-5080 in terms of synthesizer engine, and also has extremely similar MIDI implementation [18], the SD-80 can be seen as a XV-5080 with locked-down samples. What the StudioCanvas series does improve over its SoundCanvas predecessors, is its editability in native mode, which is brought on par with its professional counterparts and allow the user take full control of the sound for the first time [19]. This is a huge step forward from the lame set of a few parameters offered by earlier GS models. However there is also stuff found in earlier models that’s no longer available in the StudioCanvas, which we are going to touch on in a moment.

SD-80’s sound content

Only a small chunk of SD-80’s content is brand new (at least to me) – for example, the harpsichord [20], the clarinet, a few saxes and stereo crash cymbals. The rest are either from other Roland products, or modified from their existing content.

• The sample “Trumpet Vib” used by the now infamous Romantic Tp (thanks to ZUN) is from SR-JV80-18 Latin expansion board. The original sample name is “Tp Vib MariA” (or B, or less likely C) [21] There are a lot more samples for various trumpet techniques in SR-JV80-18, particularly designed for Mexican mariachi music. These samples are also found in SRX-09 World Collection, which contains all samples from SR-JV80-18.
• Acoustic drum set from the solo set is a cut down version of the studio kit from SRX-03 Studio, which is also the source of Super Quartet’s drums.
• Piano patches are pulled straight from SR-JV80-09, which is also included in SRX-07. SC-8850 has the same Piano sound. No it doesn’t. It uses the stereo piano samples from XV. Thanks for Arie on Discord to point this out.
• Clavi is almost identical to one of the many clavi patches from SC-8820/8850, and is likely ultimately from the JVs and SR-JV80 boards.
• Samples of Flute vib sound identical to those with the same name (“Flute Vib3 A/B/C”) in SRX-03.
• Samples of St.Brass and St.Sm Choir also come straight from SRX-03.
• Multiple sound effects are from earlier SC models. Some are also used by XV-5080’s GM2 mode.
• A lot of patches in the special sets are pulled from the XV-5080. They use the exact same parameters, except the waveforms. If you can find a preset with the same name as an instrument from SD-80’s special set in the XV-5080, chances are they sound almost identical, especially since a lot of them are analog/digital synth patches, and waveforms don’t matter as much. There are a few exceptions – a preset with the name “Cascade” is found in both instruments, but they have nothing in common except the name. There are also a lot of XV-5080 “inspired” patches: they have different names from the original XV-5080 patch, but very similar sound design. In fact, the “Cascade” patch mentioned above is one of these XV-5080 “inspired” patch, but you have to figure out the original yourself as I forgot which one it is.
• Rave Set, Rust Set and Bully Set are adapted versions of XV’s RaveDrumSet, XV Rust Kit and XV Bully Kit respectively. The original XV kits are not GM-compatible.
• Multiple orchestral instruments from the contemporary set and solo set use samples from SRX-06 (SR-JV80-02/16).
• Bass and guitar are a mishmash from SR-JV80-09, SRX-03, SRX-07, SRX-09 and XV-5080. Some of them are used in other Roland products. (Fingered Bs2 vs SC-8850 Heart Bass, which is also almost identical to Rock Bass in Super Quartet, and the sample is from SR-JV80-09).

This list is far from complete. There has been extensive efforts to map the multisamples in the SD-80 to XV-5080 and SRX multisamples. Here is one made by Palto. These mappings are extremely useful if you wish to recreate SD-80 patches with Roland’s VSTi plugins.

So the content of the SD-80 is actually a mixture of XV-5080, SRX wave expansion boards, SR-JV80 boards, earlier SoundCanvas patches and maybe a few new sounds. Reusing stuff isn’t surprising for Roland, nor should it be considered “bad”. They’ve been known to do this since the early SC days, where they used JV- and SR-JV80 expansion board sounds in the old SC series. Evidently, the waveforms come with XV-5080 itself include everything from the JV-2080/1080, which are in turn partially from the JV-880, and eventually from the JD-800… I’ve also noted that SuperQuartet has a substantial overlapping set of instruments with SRX-03. All I want to say in this section is that if you want to get some particular sounds from the Studio Canvas, instead of waiting for a second-hand offering, maybe look somewhere else.

Since the content of SD-80 is mostly just cherrypicked XV/SRX content, it really doesn’t need any additional praise from me. However I think it’s worth pointing out that Roland’s samples of that era, just like sounds from most other vendors, are heavily looped. They have loop periods that are quite short (usually less than a second). They are also usually heavily preprocessed. As the amount of memory used for reproducing the instruments saw a huge boom in the 2000s, they no longer sound downright “fake” or “plasticky” compared to romplers from a decade ago. However when compared against huge modern sample libraries, most instruments from these 2000s Roland romplers sound more “idealistic” rather than “realistic”, just like your average Japanese anime girls with unrealistically huge eyes. Not saying that such sound is bad, though.

The GS sounds and XGLite sounds of the SD-80 are completely trash. The GS sound set is pretty much just the SC-55 map in later SoundCanvas models using SD-80 samples. The XGLite sound set however, is notably larger than the average bottom-of-the-line Yamaha Portatones from the early 2000s (the XGLite instrument listing in SD-80/90’s manual is incomplete. Check my first SD-80 post for a complete list). There are probably only 5 or so usable sounds offered in these modes in total (most of which are in the XGLite sound set, which is kind of ironic for a Roland sound module). It’s not worth it to switch modes just for those sounds, especially since these modes don’t support low-level editing like the native mode.

The SD-80 features 1050 instruments and 30 drum sets, which is a significant decrease from the last generation SC-8850 (1640 instruments and 63 drum sets). The loss of SC-8850’s ethnic and analog instruments is a shame. But the quality of instruments does receive a general uplift.

More on SD-80 vs SD-90 vs SD-20

What does a SD-90 have that SD-80 doesn’t?

Easy. The audio interface (together with post-processing effects) and the large screen.

It is a shame that Roland didn’t implement full XV-level editability of patches on such a large screen though.

SD-80 is also not capable of switching the output sample rate on its digital audio outputs.

What does a SD-80 have that SD-90 doesn’t?

This may come as a shocker, because the list is surprisingly long.

• User instruments and user rhythm sets. [22]
• A few weird switches controlling its global state (MFX on/off, reverb/chorus switch). They are weird because they are not affected by the native mode reset message. These switches are also featured in the SD-80 editor, which Roland says don’t do anything if used with an SD-90. They are also present in the professional XV line-up.
• Multiple outputs from the synthesizer. The SD-90 does have a secondary output, but the internal synthesizer can only use one of them. The SD-80 has two stereo outputs, which can also be used as four mono outputs. This also allows the SD-80 to have…
• Ability to output synthesizer effects to a separate bus. You can specify the output for the internal reverb, chorus and multi-effects as well.

What’s the SD-20 anyway?

Turns out it’s not much.

There’s going to be a separate article on this.

What role does MFX play?

It depends. If the MFX is just some reverb, EQ, or chorus, it really doesn’t make a whole world of difference and can be easily replaced with basic external effects. If its an amplifier simulator, a pitch shifter, or an auto filter, disabling MFX will result in a drastic sound change. Plugins simulating these effects are also usually harder to come by / more expensive. A few demonstrations of patches with and without MFX are in the table below.

Light Load vs High Load

There is a toggle for “Light Load” mode in the driver for SD-80 on all platforms, including Linux. What this option actually does is not documented. The only thing I know is that in the Linux driver this is implemented with a single usb_set_interface call.

This setting doesn’t seem to affect the synth engine, only the way how midi data is transmitted / processed (because the drivers for UA-25 has this option as well). Weirdly, Roland’s contemporary software synthesizers (HyperCanvas/TTS-1, SuperQuartet, Orchestral) also have this option.

Block Diagram

I made this vectorized version of SD-80’s block diagram printed on its chassis when I was bored. You can also get a rasterized version.

Other weird and interesting stuff

• Very few (if any) preset patches uses the modulation matrix of the XV engine correctly. All of them has the modulation source set to ‘OFF’.
• Only 5 of all preset patches used non-default tone structures: “Runaway Rez”, “Purple Spin”, “FM layer”, “FM Delight”, and “Xmod EP”. All of them are in the special sets. 3 of them are unmodified XV-5080 patches.
• There doesn’t seem to be a way to set the system tempo of the SD-80/90 with MIDI messages, nor can the SD-80/90 sync its MIDI clock with a host, rendering the system clock mostly useless. Neither of these two is true for the XV-5080.
• Ever wondered why some patches have seemingly nonsensical waveforms selected in disabled tones [23]? Just look up those wave numbers in the waveform list of XV-5080 or the corresponding SRX board! [24] This, once again, suggests Roland used the XV-5080 as the development platform for the StudioCanvas.
• From Sound On Sound’s review of the SD-90: “To me, however, USB audio and the Sound Canvas sound set don’t add up to £799, and although I grew to like the SD90, I’m not sure how many people will find it attractive at this price point.” – ZUN, apparently.

Errata of the original post

• The non-zero “modulation level” (which is actually “modulation depth”) on the SD-80 isn’t the value of the modulation wheel itself, but rather how deep a modulation wheel pushed all the way to the top will modulate the sound. SD-90 also has a default value of 10 for it (“Mod LFO Pitch Depth” in the address mapping). There’s no GM incompatibility here.
• Instruments sampled with vibrato are not from the XV-5080, they are from the SRX / SR-JV80 boards. Duh.
• XP6 was used in professional products. In fact, a handful of them (XV-3080, XV-88, JV-1010 and possibly more).
• Roland still makes romplers today. It’s a model from a decade ago. You’ll have to guess which model it is.

References

• Roland Wave Expansion Cards by Edward D-tech
• Don Solaris’ ultimate Roland JV/JD/XV FAQ
• What is COSM?
• SOS Review of XV-5080
• SOS Review of SD-90
• SOS Review of SD-80
• SOS Review of SC-88