zaphod77 wrote on 2026-08-27, 00:58:

oh, never mind, apparently vstmidi driver doesn't actually know how to handle port 2 unless you are using FSMP.

It's not the concern of VSTi Midi driver to handle multi port Midi files since a driver never sees the Midi file itself. It is the concern of the Midi player to send messages to either Port A or Port B depending on the port select meta event(s) stored in the Midi file's tracks. Meta events are not part of the Midi protocol so they cannot be sent to devices/drivers like normal channel or SysEx messages. So you have to use a Midi player that can send messages to multiple ports and can recognize the meta events used by the Midi file.
VSTi Midi driver can also handle the seldom documented 0xF5 real time messages (that can be sent to drivers/devices ) to support 32 channels through a single port but as you said only FSMP uses this message type so far.

well, when i load up the unmodified midi file into cakewalk it shows port 1 and port 2, but then says they are both port a, and vst midi driver loads up and only binds to port a. If i load the midi file into tabula sonora web page, it works. if i load it into foobar2000 with foo_midi and Secret Sauce, again it does the right thing, and plays back as 32 channel.

On the other hand, if mame was working properly, i could hook up a virtual midi cable to both midi ins, and if i then had a really simple midi player that understood the standard port select meta events, i'd be able to play that back.

Now as I understand it, the actual VSTI of SCVA is crippled, and only supports 16 channels, and takes ages to load up, so bypassing it and going straight for sccore.dll seems to be the way to go.

Now there's no such thing as open source vst2 stuff, because steinberg is being a pill.

BUT, we do have open source for foo_midi with secret sauce.

https://github.com/stuerp/foo_midi

And we do have source for tabula sonora, which can pretty much do the same thing

https://github.com/TabulaSonora/NativeTS

so with the help of one of these it should be possible to make your midi player playback multiport midis using SC VA's sccore.dll.

Tabula sonora ALSO seems to understand actual channels higher than 16 as well, which is quite interesting.

Tabula sonora requires owning the latest version, while Secret Sauce can do the trial DLLs, which is important, as the trial is still downloadable from Roland. Meaning foobar 2k+foo_midi is an option for those who failed to purchase sc va!

I hope the new emulator will provide a way to allow a player to access all the parts.

Yes, sccore.dll has zero drm, which appears to allow the creation of scpipe without breaking the DMCA, which is part of the foo_midi source code.

Secret Sauce is executing the original code, Tabula Sonora only uses select data tables from the module. I am tracing down how to make it work with the 2016 version, but it will require some processing.

zaphod77 wrote on 2026-08-27, 06:19:

well, when i load up the unmodified midi file into cakewalk it shows port 1 and port 2, but then says they are both port a, and vst midi driver loads up and only binds to port a. If i load the midi file into tabula sonora web page, it works. if i load it into foobar2000 with foo_midi and Secret Sauce, again it does the right thing, and plays back as 32 channel.

Yes, sccore.dll has zero drm, which appears to allow the creation of scpipe without breaking the DMCA, which is part of the foo_midi source code.

Well, Cakewalk definitely will not send Midi messeges to different Midi Out ports according to meta events in the Midi file. None of the DAWs I know can do this. In DAWs usually you can assign different Midi tracks to different Midi ports or virtual instruments manually and the config can be saved to a DAW project.
So in Cakewalk you have to assign the Midi tracks that have port select meta event (0) to VST Midi Driver port A, and the Midi tracks that have port select meta event (1) to VST Midi Driver port B.
Some Midi files meant to be played on dual port SC-88(Pro) do not even contain port select meta events but simple text meta events like 'PartA 1ch','PartA 2ch'/'PartB 1ch', 'PartB 2ch' etc. Then you have to assign the Midi tracks to Midi Out ports according to these text events.
And of course there are many other creative ways how authors marked the original intention since there has never been a standard way how multi-port logic should work based on the SMF specification.

What? SC-VA decomp? Holy moly, this wasn't on my bingo this year, or any year, for that matter

First TG100 VST, now this, the retro synth community isn't just eating good this year, we are having an outright feast

SO here's what we have so far for xg/gs midi.

1) THe infamous abandonware s-yxg50 softsynth, an dquite as few modified versions from russia. Known to haver a few bugs, but is pretty solid. Plays back XG midi very well, less accurate for GS. NOt subject to orignal polytphony limit.
2) The famous abandonware Sound Canvas VA. Has a few bugs, but does a better job with most GS midis that use the TVF. Subject to the sc8820 limits on polyphony.
3) Nuked-SC55 (flawless mark 1 emulation, slightly flawed mark II, because the mark II pcm chip is not decapped and reversed yet, and this fixes a bug present in the mk1 that affects you if you use a mkII control rom and a mk1 pcm chip. Subject to original device's polyphony limits.
4) mame's mu series emulations. still in progress, and only provide midi in ports, not serial. Supports 32 channel midi playback, if your DAW/player can use multiple ports. no known way to do 64 channel. Subject to original limits.
5) Tabula Sonora (available currently for those who possess a sccore.dll from the latest 64 bit Sound Canvas VA. pretty darn good, and even fixes a few bugs that exist in the SC VA. supports 64 channel playback across 1 to 4 ports.
6) Emu88 project: not yet released, supports sc88(pro) and sc8850. possibly others. Will almost certainly map both midi in ports, and may or may not make an emulated serial/usb Roland midi device. Almost certainly obeys orignal limits.
7) foo_midi's secret sauce which bridges foobar2k and sccore.dll directly. Supports 32 channel midis.
😎 Speesasynth supports most gs stuff now, and if yo uhave a fake sound canvas soundfont, AND don't need to use the filter, it does a decent imitation.

Anything i've missed?

MU emulation being confined to MAME is very sad tbh, after all this time you'd think that at least somebody would make a VST2/CLAP fork, like how there's a CLAP fork of Nuked SC-55 (foo_midi being able to use Nuked SC-55, even if only through the CLAP fork, is a very huge advantage that FSMP doesn't have)

>"Subject to original device's polyphony limits."

Depends. During normal playback, yes, but the MIDI renderer tool has a command to bypass the original polyphony by emulating additional number of units, i.e. 2 for 48 polyphony, etc etc

zaphod77 wrote on 2026-08-29, 00:27:

Anything i've missed?

Yeah, https://github.com/skjelten/emusc. Which is another SC55 emulator. Version 0.7.0 was released a couple of weeks ago.

It's still not perfect, but it's much closer than it used to be.

New update? And a pretty big one too? I thought that emusc was killed off after Nuked SC-55 was released. With Nuked SC-55 now being the one dead, emusc came back to pick up the mantle, it seems

I'm saddened that nuked sc-55 is now dead, because it only is perfect for the original non mkII devices (it emulates older PCM chip used in the original, and NOT the one present in the mkII)

Anyway, i don't think emulating multiple copies of the device counts as bypassing the polyphony limits. 😀

Until the emulations in MAME reach parity with the original device i don't see a VSTi/CLAP plugin getting made.

Ye, nuked SC-55 being is pretty sad (last commit on original repo by nukeyt almost 2 years, on jcmoyer's fork last commit this May), but EmuSC has been extremely active, getting several commits almost every day, if it continues development at this rate then sooner or later it will overtake nuked SC-55 as the main and most accurate SC-55 emulator

Davedson wrote on 2026-08-29, 15:59:

Ye, nuked SC-55 being is pretty sad (last commit on original repo by nukeyt almost 2 years, on jcmoyer's fork last commit this May), but EmuSC has been extremely active, getting several commits almost every day, if it continues development at this rate then sooner or later it will overtake nuked SC-55 as the main and most accurate SC-55 emulator

EmuSC could only get this traction by the grace of Nuked SC-55.
A development like this was to be expected. Nuked SC-55 is a 2xCPU emulator.running the original ROM code. but very heavy on the CPU.
Still, Nuked SC-55 is a milestone reference (what you call dead).

well, when you put it that way, ye, "milestone reference" sounds better than "dead"

yeah, it was and still is a great accomplishment, and the Clap plugin of it is awesome. main thing i was wondering is if the pcm chip bug that messes up filters in the mkII would get fixed.

And both probably would make a very nice reference for something that only uses the rom to get instrument data, and is much easier on your CPU.

say what you like about s-yxg50, it's very light on the cpu, as it was running back in the 90s on period hardware, with current computers being able to easily do 256 polyphony per instance.

Davedson wrote on 2026-08-29, 09:43:

MU emulation being confined to MAME is very sad tbh, after all this time you'd think that at least somebody would make a VST2/CLAP fork, like how there's a CLAP fork of Nuked SC-55 (foo_midi being able to use Nuked SC-55, even if only through the CLAP fork, is a very huge advantage that FSMP doesn't have)

Here is a 64-bit CLAP to VST2 wrapper that can be used with the 64-bit FSMP for Nuked SC-55 CLAP plugin version. You have to simply copy the Nuked-SC55.dll file next to Nuked-SC55.clap (usually in C:\Program Files\Common Files\CLAP) and open the .dll file instead of the .clap file in FSMP's VSTi dialog.
At 1st start you get a list of the different ROM versions as a VST program list. Currently you have to explicitly select a different program than default program 0 to get sound. I still do not know why. Later you can select program 0 again and it will work. If you already saved the plugin settings and also checked 'Autoload Last Used Settinf File' then this problem does not happen anymore.

Wow, thanks. Did you just make it yourself? I tried to find anything on CLAP to VST2 wrapping but found only the official tool that doesn't support VST2, only 3, and no other wrappers exist

Davedson wrote on 2026-08-30, 07:05:

Wow, thanks. Did you just make it yourself? I tried to find anything on CLAP to VST2 wrapping but found only the official tool that doesn't support VST2, only 3, and no other wrappers exist

Yes, but this is just a draft/test version. Currently It cannot work even with my own version of VST Midi driver 😀 But FSMP can use it even with other CLAP plugins if you rename the wrapper accordingly.
I also tested it with the CLAP version of TG100 and it works even better than Nuked SC-55 CLAP version.
https://www.martinic.com/en/dev/tg100/downloads

You probably should make it into a separate open source project, I bet there will be a lot of demand for it from people that would want to use CLAP plugins in old DAWs

Davedson wrote on 2026-08-30, 18:08:

You probably should make it into a separate open source project, I bet there will be a lot of demand for it from people that would want to use CLAP plugins in old DAWs

It's formally released now. The release version also works with VST Midi Driver. Currently it's not open source but free to use. The main release post:
Re: Falcosoft Soundfont Midi Player + Munt VSTi + BassMidi VSTi

There probably should be a separate thread on VOGONS about Tabula Sonora, using this thread for it is kinda off topic