Does anyone know what was the latest version of SC-VA ever released? No matter how hard I searched on the internet the farthest version I could find was 1.16 released in January of 2020
Coooooooooooool.
So this is a solution for those who own the program, and were able to download the latest version while it was around, right?
There are 32 and 64 bit versions of this dll, and i'm not sure which versions have which SCCore.dll files. i know that last 32 bit version i found has a different size than expected by this.
just tested with right in the night. tvf doesn't seem to be included.
TVF is supposed to be handled. I know this whole thing needs more work.
For clarity, it needs the 2020 version, 64 bit build. I will try to see if I can also swing MAME ROM sets for the data, assuming MAME even has dumps of the SC-8820 to go with their existing dumps of the 88 and 88 Pro.
kode54 wrote on 2026-08-01, 08:39:TVF is supposed to be handled. I know this whole thing needs more work.
For clarity, it needs the 2020 version, 64 bit build. I will try to see if I can also swing MAME ROM sets for the data, assuming MAME even has dumps of the SC-8820 to go with their existing dumps of the 88 and 88 Pro.
Awesome work. I have a fork created and I have started a C language port in the works. I found a few bugs and inaccuracies along the way that I will PR soon. My goal is to get it bare metal compatible for the MT32Pi.
I will link my test midi file.
https://gifx.co/music/MIDI%2FJam%20%26%20Spoo … The%20Night.mid
the reverse cymbal should do three wooshes each time, and there is a filter sweep that goes back and forth near the end of the file.
This midi should be compared against Sound Canvas VA itself.
Kim Burgaard has made quite a few GS techno midis which also make good test cases for this.
mame does not seem to have the sc8820 roms yet.
so this means the sound canvas VA is truly made with the 8820 samples? that's actually pretty cool.
There are two other commonly available versions of sccore.dll
1) 1.0.3 32 bit
2) 1.1.2 64 bit
and the'r also the window strial
https://cdn.roland.com/assets/media/zip/scva_win_trial.zip
Which is still available.
it's possible to extract the SCCore without installing.
The trial comes with both 32 and 64 bit versions of the sccore.
install univeresal extractor 2 https://github.com/Bioruebe/UniExtract2
give the single exe the command.
SOUND_Canvas_VA_Installer.exe /extract_all:c:\directory
thsi wil convert it do a normal split file, with the setup adn installshield cab files.
you may then run universal extractor 2 on the data2.cab file.
this will extract everythign into a new data2 subdirectory, with both
SoundCanvas64
and
SoundCanvas32
directories. you then have the SCCore.dll files, without breaking any drm to find them.
I dunno if kode54 can make use of trial version sccore.dll files, and if so, if they are actually willing to extract the sample data from them. If the intent it to only support purchased versions, i have no quarrel with that stance, even though the product can no longer be purchased.
I am confident that the 32 bit 1.0.3 and 64 bit 1.1.2 found in common portable versions can found in some archive somewhere on the internet.
As i said, the trial still exists on rolands servers, and i was able to find the url by inspecting a webpage on in.roland.com (the indian roland site)
mac trial is
https://cdn.roland.com/assets/media/zip/scva_mac_trial.zip, btw. dunno how to extract from it, but presumably the trials install fine.
Thanks for the example MIDI file. Feel free to keep up with the changes to the repo for new work being added, and we'll try to keep up with your documented forks as well for integrating information into the spec repo, unless you feel like also making PRs against the spec repo to document things along the way.
I rewrote history, but the differences code-wise are minor. It was just getting rid of some system absolute paths from parts of the repo. This will be my only rewrite, going forward. The commits still have the same summaries and full commit messages, so they should line up just fine with a reckoning of differences.
I based the RE on the SCCore.dll file that was bundled with version 1.1.6 of SCVA.
The Wave ROM data should be the same between them all, the only thing that should be changing is either the engine implementation or the parameter data, if they had inserted errors into that when transcribing it in the original port.
The C# implementation was also not meant to be the authoritative implementation, but the first attempt to implement it at all. Feel free to make a fresh implementation, either from it, or using it as a guide. We'll look into folding in any research you find along the way, but we're still documenting things in the decompile.
Also, regarding purchased, I didn't intend to restrict this to only purchased, only to make this semi-legal as a preservation effort. The final commercial version was just what we started this decompilation on. Certainly, older versions could be used to reference some or all of the data. And trial has no effect on SCCore itself, since that library is not any different trial or purchased. The DRM lives entirely in the plugin portion, SCCore and company are just a raw 8820 implementation.
The splitting that happened with the macOS version was because they learned early enough that modifying the binary to support unique memory addressing for multiple instances broke code signing. So they split it up so that there was a single .dylib with the ROM data shared, and then individual smaller .dylib files with the read-write data and the core code sections.
This implementation we produced would already be easy enough to make reentrant, something that Roland never bothered to do.
This should hopefully be relatively safe to keep documenting, since Roland decided to kill the product, even if they are still distributing trials you can no longer purchase.
In that case, i'd test with the trial, which definitely has an unmodified SCCore.dll file. I've described a working extraction procedure to get the DLL regardless of any other installed version.
unfortunately, tools\gen_manifest.py fails to operate correctly for me. it always finds zero tables, unless some have already been extracted, and leaves most of them out of manifest.json
it seems there were changes made that other versions need to be specifically supported.
I have confirmed that trial 32 bit SCCore.dll is exactly the same as 1.0.3 32 bit. fc /b reports no differences encountered.
Note that my test midi file was composed for sc55. meaning it doesn't have any instruments the sc55mkII does not. so pretty sure it doesn't use any insertion effects. that's why it's a good test midi. a number of other gs midi files are out there that use two drum channels. that should be tested as well.
you can find rtft.mid in this archive.
found rtft.mid and absensce.mid finally
With the 32 part commit does this confirm that the vsti uses the same engine code from the SC-8820 hardware but with slight modifications?
Please note that https://tabula-sonora.kddlb.cl is now based on a C++ port of the engine at https://github.com/TabulaSonora/NativeTS
Heads-up, most of the work has been handled by an LLM, but the LLM has no ears, so...
Incidentally, the ROM dump information and structure perfectly identifies why the SC-55 mode does not sound exactly like an SC-55: This does not feature the SC-55 samples, it features SC-88, SC-88 Pro, and SC-8820 additions. The SC-55 mode uses its own partial sets, including its own drum kit partials, but they still sample from these three wave sets.
Also, the incompatibility of the hardware synthesizer chip being similar to the SC-88 and 88 Pro, rather than the 55. It also already has double the polyphony of the SC-55.
Among the features I've implemented, are also including custom polyphony settings, including a self-growing "unlimited" mode, which is only limited by system memory available to it, and CPU resources to drive that many voices. Currently, the TUI defaults to 64 parts, 256 polyphony, and many files that would have hit the old limits almost never hit the new limit, so 256 is more than enough for regular use, and only halves the performance, roughly. It's still 15-20x realtime at heavy utilization on a Ryzen 9 9900X, and that's only because it's still limited by single core performance. Still more than fast enough for regular use.
Also, I definitely found the XG compatibility mode. It has its own unique partial map, its own unique drum kits, following the XG layout of drum notes, and it also has the behavior of bank LSB controlling the variations, bank MSB 64 selecting the SFX sets, and bank MSB 127 setting arbitrary channels to drum kits. And a huge selection of XG System Exclusive messages, but no variation yet that I know of. In addition to the original design, I've extended it: It supports the full 64 parts of an XG system, rather than crashing on out of bounds access to parts 32-63. It also supports the drum presets 1-4, and unlike the original, correctly limits this parameter to valid values, instead of either corrupting the heap or crashing. It may be worth testing if a real SC-8820 suffers crashes when fed XG parts 32-63. If it has an XG compatibility mode like the SCVA direct port does, then it likely has the same bugs. The XG mode only activates with an XG System On message, and also deactivates itself if a GS message is subsequently received.
Huh, searching for Sound Canvas VA 1.1.6 finds an Archive.org upload of several installers. Been there since 2021, a year after the last update, but before it was officially killed. Probably not safe to link.
The one i found had the 1.16 64 bit installer, 1.0.3 32 bit portable, and 1.1.2 64 bit portable.
And as i've said, the windiows trial contains 1.0.3 32 bit and some other 64 bit version, which i don't i know what it is.
I'm particularly interested in how the xg compatibility mode creates the xg normal instruments, as yamaha had to bring in exclusive gs samples for it's gs modes.
I'd also like to see what happens if this rom is converted to a soundfont, with the proper defaults for the sample's tvf and tva settings used, and then plugged into something liek spessasynth, which sould then sound very close to the SOund Canvas VA.
I could develop a SoundFont converter, possibly with dynamic allocation to unused banks in the SF2 itself, and using .sflist.json maps to pick out the mapped banks for the five maps (55, 88, 88 Pro, 8820, and XG).
It would also end up super big, unless I implement support for the compression format as an extension to the SFe format, just for this task. Since the original data is effectively 8 bits per sample plus a fraction, for the 4 bit scale factor per 16 samples.
I will look into it, as one of my upcoming tasks.
Here's what i would actually like to see among the output soundfonts.
1) sc55mkII with CTF
2) sc88 with ctf
3) sc88pro with XG mode and ctf
4) 8820 with xg mode and ctf.
number 1 is actually the one i'm most interested in. something that with a fully compliant synth (fluid/bassmidi/spessasynth)should playback the three midis i've linked correctly.
