Roland User wrote on 2026-08-26, 10:42:

RetroGC , your offer not mean sense because for this work , you need have GS compatible soundfont or GS compatible MIDI Device , […]
Show full quote

RetroGC , your offer not mean sense because for this work , you need have GS compatible soundfont or GS compatible MIDI Device , if this remove to SFX Kit 56 key how you offer , then when users will be play MIDI on standard soundfont whitch General MIDI compatible , they not be hear gunshot because in Standard Kit this sound absent ) because how I known , this sound available only in SFX and CM 32/64 drumset , in all other drumsets this sound if not considered variants drumsets of SC-88 Pro and later , this sound not provided of standards )
and also , how be if gunshot patch mean :
0 128 Gun Shot
1 Machine Gun
2 Lasergun
3 Explosion
4 Eruption
5 Big Shot
6 Explosion 2
you get move gunshot to SFX , but how be if patch nubmer 127 / 128 , and bank number not 0 ? What do if this variant ? )

There's few missunderstanding here. I was asking this just for some midi files derived from vgmtrans. As you know that kind of midi files have an associated sf2 palette and usually drum's channel is on gunshot instruments (at least on dragon quest 6). It's not intended for real midi files using that sound. Aldo

Any chance of implementing "secret sauce" from foo_midi?

(this is a way to load the actual synth emulator form sound canvas VA directly, which is used by foo_midi for foobar2k player.

https://github.com/stuerp/foo_midi/tree/main/scpipe

https://github.com/stuerp/foo_midi/tree/main/Players

possibly useful code here?

zaphod77 wrote on 2026-08-27, 20:40:

Any chance of implementing "secret sauce" from foo_midi? […]
Show full quote

Any chance of implementing "secret sauce" from foo_midi?

(this is a way to load the actual synth emulator form sound canvas VA directly, which is used by foo_midi for foobar2k player.

https://github.com/stuerp/foo_midi/tree/main/scpipe

https://github.com/stuerp/foo_midi/tree/main/Players

possibly useful code here?

Midi Player is not written in C/C++ so not in a straightforward way... I would rather wait for the new open source implementation of SV-VA to be ready.
Besides a GUI-less SC-VA is not that attractive for me so I do not feel the urge to spend days with this, I'm sorry.

Tabula Sonora already exists. There's a python reference version, a .net version, and a Native C++20 version. But since Midi Player is not written in any of those, i don't see how that will help, unless you can port.

you can already see NativeTS running in a web browser here. https://tabula-sonora.kddlb.cl/ It doesn't have the sound canvas gui either, though it does provide it's own.

Note that the actual sc88(pro) has an ALL button. pressing this will show the bars for port a at the bottom, and port b at the top. the 8850 and probably the actual 8820 appear to let you page between the parts.

A fully emulated sc88(pro) should support both dual midi in mode, and emulated serial mode. For the 8850 and 8820, that is the only way to actually address the second half of the 64 channels.

as i said mame implementations of the mu devices don't seem to provide the serial interface at all. just the midi ins. which provide no access to 33-64.

Yamaha devices support a protocol called TO HOST over serial. software supporting yamaha devices use a driver to convert the midi data to the TO HOST protocol, which can then be sent out the rs232 serial port, which is then adapted to the mini DIN on the devie with a proper cable.

I'm not sure what roland uses to do the same thing.

Either way, the driver provides virtual midi ports, and negotiates a baud rate, when data is sent to the virtual midi ports, the driver converts it to the proper serial protocol, so it can be sent across the serial port or the usb port depending onte driver.

Also, the 8820 is cut down to 32 channels and 64 polyphony, and has only one midi in. SC VA replicates this, while tabula sonora does not, and can do "infinite polyphony" and 64 parts, spread over 1, 2 or 4 ports. This is why when yo uload sc va as a vst, it only attaches to one midi port, and it oddly enough jsut masks out the other channels with an AND 0x0F. This is probably fixable by patching sccore.dll somehow.

zaphod77 wrote on 2026-08-28, 04:06:

Tabula Sonora already exists. There's a python reference version, a .net version, and a Native C++20 version. But since Midi Player is not written in any of those, i don't see how that will help, unless you can port.
...
Also, the 8820 is cut down to 32 channels and 64 polyphony, and has only one midi in. SC VA replicates this, while tabula sonora does not, and can do "infinite polyphony" and 64 parts, spread over 1, 2 or 4 ports. This is why when yo uload sc va as a vst, it only attaches to one midi port, and it oddly enough jsut masks out the other channels with an AND 0x0F. This is probably fixable by patching sccore.dll somehow.

1. Maybe it was not clear but I did not mean that I would integrate the open source SC-VA into Midi Player. I meant that when it is fully ready I do not have to do such thing since it can be used either as a standalone device through Midi ports like Nuked SC-55 or as a plugin like the original SC-VA.

2. I'm pretty sure that the reason of why the original SC-VA plugin uses only 1-port/16-channels is related to its VST2 architecture. S-YXG50 behaves the same way: while both the Win9x vxd and the WinXP WDM driver versions of S-YXG50 support 4-port/64-channels with the help of the 0xF5 real time Midi messages the VST plugin version does not. The plugin version only supports 1-port/16-cahnnels the same way as SC-VA. In VST environments most hosts know nothing about 16+ Midi channels through a single port or the possible existence of multiple ports inside a single plugin. The majority of VST instrument plugins are not even multi-timbral. This is because in DAWs you can use as many instances of plugins as you want and assign them to any Midi programs in a DAW project.

I'm pretty sure s-yxg50 only supports 16 channels, because the MU50 only supports 16 channels.

zaphod77 wrote on 2026-08-28, 16:05:

I'm pretty sure s-yxg50 only supports 16 channels, because the MU50 only supports 16 channels.

Then the Win9x and WinXP driver versions of S-YXG50 why support 4 ports /64 channels ?

BTW, I have actually tested both Win9x and WinXP driver versions so it's not just a theory. Both driver versions accept and perfectly handle 0xF501 -> 0xF504 while the VST2 plugin version does not.
Here is a test video that proves at least the 2-port/32-channel compatibility of the WinXP driver version:
1. The 1st part shows that the played Midi file actually uses Both Port A and Port B of VstMidi Driver and thuu can be considered as the reference sound.
2. The 2nd part shows that a.: actually the WinXP driver is used b: it sounds exactly the same as the 1st part that is proven to use both ports A and B.
3. The 3rd part shows that the VST2 plugin version itself cannot handle the multi-port stream the same way so it sounds completely differently and completely off compared to 1 and 2.
https://youtu.be/iriDGO0AK9s

BTW, the 1st Yamaha document I could find that mentions support for 0xF5 messages is the MU80 manual.

That's very interesting, because the mu-50 does not support more tha 16 channels ever.

and s-yxg50 is clearly based on mu50.

But yeah, you seem to be right about vst2 sucking. vst3 and CLAP are both capable of hosting multiple ports in the same virtual instrument. And it seems VST3 IS open source.

it just really sucks to use scva.dll, be limited to 16 channels per instance, and duplicate such a slow loading VSTi. SEcret SAuce and Tabula Sonora seem better solutions that allow access to the other parts when supported by a player.

And i'm still VERY curious how the new emulator will expose all four sets for SC8850, because not even original hardweare can do this without the serial DIN/USB port.

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

...
But yeah, you seem to be right about vst2 sucking. vst3 and CLAP are both capable of hosting multiple ports in the same virtual instrument. And it seems VST3 IS open source.

Yes, but VST3 abstracted Midi away so handling even a simple Program Change message properly on all kinds of VST3 hosts is practically impossible. Not to mention emulating stuff like the 2 bank dimensions of XG (Bank MSB + Bank LSB + Program Change addressing).
CLAP is a much better architecture in this sense.

no argument there. CLAP was actually designed for MIDI, so that helps a lot.

GS does the same thing, using both lsb and msb bank select, but it's used for different purposes. The real annoying thing is that xg devices usually have a TG300B mode, which responds like a sound canvas would. THAT'S the really annoying part, because one uses LSB as primary, and the other one uses MSB as primary. It REALLY annoys people trying to make soundfonts to support both midi standards.

zaphod77 wrote on 2026-08-29, 06:17:

no argument there. CLAP was actually designed for MIDI, so that helps a lot.

GS does the same thing, using both lsb and msb bank select, but it's used for different purposes. The real annoying thing is that xg devices usually have a TG300B mode, which responds like a sound canvas would. THAT'S the really annoying part, because one uses LSB as primary, and the other one uses MSB as primary. It REALLY annoys people trying to make soundfonts to support both midi standards.

Yep, and the standar SF2 format does not support LSB addressing at all. More precisely it supports only 1 bank dimension and that is bank MSB by convention.

Hi,
In order to help both FSMP and VST Midi Driver to use CLAP plugins (mainly Nuked SC-55 CLAP plugin version) I have written a CLAP to VST2 wrapper.

Usage
------
Place the wrapper DLL and the corresponding CLAP plugin in the same folder, using the same base name.

For example:

MyPlugin.dll
MyPlugin.clap

The wrapper automatically loads the matching CLAP plugin when the VST2 host loads the DLL.
If a CLAP plugin contains multiple plugins, they are made available as separate VST2 programs. Changing the VST2 program selects the corresponding CLAP plugin.
For virtual instruments, MIDI input is passed to the CLAP plugin and its audio output is returned to the VST2 host.
Most likely you have to use the wrapper dll from the x64 folder. Although 32-bit CLAP plugins are possible in theory I have never met one so far. If you have a 32-bit CLAP plugin then you have to use the 32-bit wrapper dll from the x86 folder.

Example
--------

To use Nuked-SC55-CLAP through a VST2-only application like FSMP or VST Midi Driver:

Nuked-SC55.dll
Nuked-SC55.clap

Load Nuked-SC55.dll in the VST2 application and select the required program.

Warning:
Currently in case of Nuked-SC55 plugin 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. Both in FSMP and VST Midi driver you should save the plugin settings and (auto) load it next time to prevent this problem.

The wrapper can be downloaded from here:
https://falcosoft.hu/clap2vst2_10.zip

In case of FSMP use the x64 version of FSMP with the x64 version of the wrapper:

zaphod77
I not known what you want , but if your target very more polyphony , so this for you MIDI Router , you can use difference mode and set one synth to one channel , and if this , you get all polyphony one copy on one channel , you can get 1024 voies if will use 16 copys Roland SCVA , be the way , my solution support translate full sysex messages in difference mode to all channels ) that's why you not leave without sysex effects on your copyes synth on difference channels )
Also my MIDI Router supported merge mode , then when you select seveal input ports , and do sent all stream to one output port , but if this use , you may recive a garbage of sheet music on output device ) so will be careful )

I just want the emulated device to actually support all 32 or 64 channels in one instance. it's apparently a limit of VST2, which vst3 and CLAP can bypass.

Anyway, Tabula Sonora now can read the trial dlls properly, which as i said are the ones people can actually get and be legal. This means tabula sonora spec can be used to implement vst2/vst3/clap plugins, or standalone players that fetch data from sccore.dll, as an alternative to Secret Sauce in foobar.

As i said, this matters because non owners can install the trial, which is still on rolands servers unprotected, copy out the sccore.dll and then use it with Secret Sauce or any project based on tabula sonora. non windows users can use extraction tools to pull this DLL out of the installshield installer. As i have 1.16 installed i didn't want to risk installing the trial, so I had to work out that trick to pull it out. there are other ways to get the dll, but pulling directly from the trial is something that we should be able to advise people to do on here. 😀

Currently, the standalone windows player still only accepts the final 64 bit version. I'm trying to build it now.

So tabula sonora exports a soundfont, but it doesn't used a normal map. i can't figure out how to apply a sflist.json file to it to map the bankjs where they are supposed to be.