From 5f05a701a18f724e1fc8ea49674dff0e96247262 Mon Sep 17 00:00:00 2001 From: Chris Xiong Date: Thu, 30 Jun 2022 15:50:12 +0800 Subject: oops left some demos over --- blog/post/2020-11-20.html | 106 ++++++++++++++++++++++++++++++++++------------ 1 file changed, 80 insertions(+), 26 deletions(-) (limited to 'blog/post') diff --git a/blog/post/2020-11-20.html b/blog/post/2020-11-20.html index 8abf74e..245b88d 100644 --- a/blog/post/2020-11-20.html +++ b/blog/post/2020-11-20.html @@ -117,7 +117,7 @@ for(let x of al)

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 procratination.

+

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

My special thanks go to:

-
  • 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, gettings 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 charistics 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).
    • +
  • 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 hightest 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 wraping, 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).

    +

    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).

    @@ -380,7 +380,7 @@ for(let x of al)

    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 indestructive 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.

    +

    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

    @@ -389,13 +389,67 @@ for(let x of al)

    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.

    -

    AMEDLEY.MID by Earl Gray Fowler from Voyetra Technologies, arranged for SD-80 (Native Mode)

    +
    + + + + + + + + + + + + + +
    +SD-80 + +SD-20 Converter +
    + + + +
    +AMEDLEY.MID by Earl Gray Fowler from Voyetra Technologies, arranged for SD-80 (Native Mode) +
    +

    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.

    -

    YOSEMITE.MID by Passport Designs, arranged for SD-80 (Native Mode)

    +
    + + + + + + + + + + + + + +
    +SD-80 + +SD-20 Converter +
    + + + +
    +YOSEMITE.MID by Passport Designs, arranged for SD-80 (Native Mode) +
    +

    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. The converter actually sounded exceptionally good, and exceeded my expectation by quite a large margin.

    +

    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.

    @@ -417,7 +471,7 @@ for(let x of al)

    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 relase of these plugins, the performance will probably suffer).

    +

    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…

    @@ -1231,9 +1285,9 @@ Reverb, Chorus, MFX (16 slots, 67 types), EQ, compressor (drum part), Surround, -

    The following section summerizes generation-over-generation improvements of the synth engine noticed by me reading the manuals. It is not based on analysis of the actual chip, but instead 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.

    +

    The following section summarizes generation-over-generation improvements of the synth engine noticed by me reading the manuals. It is not based on analysis of the actual chip, but instead 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.

    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 referrred 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.

    +

    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)

    @@ -1316,12 +1370,12 @@ Reverb, Chorus, MFX (16 slots, 67 types), EQ, compressor (drum part), Surround,

    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 unrealisticly 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 intrument 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.

    +

    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-proccessing effects) and the large screen.

    +

    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?

    @@ -1469,13 +1523,13 @@ Stereo Auto Wah

    References


    -- cgit v1.2.3