Falcosoft wrote:

What software cable you use to connect ScummVM to Midiplayer

I configure ScummVM to output to "Midi Through [ALSA]", and configure Midiplayer to use "Midi Through Port-0" as input. Normally I use the "VirMIDI" virtual hardware MIDI ports, but ScummVM doesn't seem able to output MIDI to them. It only works with the pass-through MIDI sequencer port.

There is no third-party "cable" software involved or anything. The "Dummy MIDI-through Sequencer" and "Virtual MIDI" are built-in into the Linux kernel. You just have to load the kernel modules for them if they're not compiled-in to the kernel. The dummy sequencer client (Midi-Through) module is called "snd-seq-dummy", and the virtual hardware MIDI ports module is "snd-virmidi".

what version of ScummVM you use? ( I mean you use the native Linux version or the Windows version of ScummVM also under Wine)

It's the Linux version of ScummVM 2.0.0.

Also what version of Midiplayer you use, 32 or 64 bit?

64-bit. AFAIK, the 32-bit version cannot load the Sound Canvas VA VST.

64-bit. AFAIK, the 32-bit version cannot load the Sound Canvas VA VST.

Of course the 32-bit version also can use SC-VA. The SC-VA installer installs both 32-bit and 64-bit version of SC-VA but into different folders.
The 32-bit version is in C:\Program Files (x86)\Roland\Sound Canvas VA (vs the 64-bit in C:\Program Files\Roland\Sound Canvas VA).
The 32-bit version of Midiplayer can use the 32-bit version of SC-VA in C:\Program Files (x86)\Roland\Sound Canvas VA.

SCVA is not available as 32-bit anymore. Only old versions (like the demo/trial installer) are 32-bit. The modern version is 64-bit only.

realnc wrote:

SCVA is not available as 32-bit anymore. Only old versions (like the demo/trial installer) are 32-bit. The modern version is 64-bit only.

Hmm. I thought this was true only for the cloud version. And the offline package still contains both 32 and 64 bit versions of the plugin. According to the Roland purchase site the offline 32/64-bit version is still available:
https://contentstore.roland.com/software/deta … ound_canvas_va/

I captured the MIDI data that is sent by ScummVM into a MIDI file. Playing that file directly in Midiplayer doesn't crash it. However, playing it from another player (like the "aplaymidi" CLI tool) using the midi-through port will crash Midiplayer. So it's got nothing to do with ScummVM.

If the midi-through port is 14, like on my system:

1$ aplaymidi -l
2 Port    Client name                      Port name
3 14:0    Midi Through                     Midi Through Port-0
4 24:0    Virtual Raw MIDI 2-0             VirMIDI 2-0
5 25:0    Virtual Raw MIDI 2-1             VirMIDI 2-1
6 26:0    Virtual Raw MIDI 2-2             VirMIDI 2-2
7 27:0    Virtual Raw MIDI 2-3             VirMIDI 2-3

Then playing the midi file with:

aplaymidi -p 14 crash.mid

will crash Midiplayer. I'm attaching the MIDI file. (The forum doesn't accept .mid files, so I had to zip it.)

Falcosoft wrote:

realnc wrote:

SCVA is not available as 32-bit anymore. Only old versions (like the demo/trial installer) are 32-bit. The modern version is 64-bit only.

Hmm. I thought this was true only for the cloud version. And the offline package still contains both 32 and 64 bit versions of the plugin. According to the Roland purchase site the offline 32/64-bit version is still available:
https://contentstore.roland.com/software/deta … ound_canvas_va/

I'll try and install the 32-bit version later.

Thanks for the test file. I could reproduce the crash with an identical port configuration to yours. Actually I could reproduce the crash with every Windows based Midi software I tried in Wine through Midi Through Port-0. Here's e.g. 32-bit GNMIDI's crash report that is identical to 32-bit Midiplayer's:

And on Windows everything is perfect, no crashes at all:
https://youtu.be/9V3-hZIkIYI

It' seems under Wine the port itself crashes and this causes the access violation (because of rather big amount of data within rather small time interval).
So you should report the bug as Wine developers suggest:

Thank you for looking into it! Looks like I'll need to file a Wine bug.

However, Wine can take years to fix bugs, so if anyone knows how, if it's possible at all, to make ScummVM use the virtual raw midi ports instead, that would be great. These ports don't crash, but ScummVM for some reason can't output to them. You can select them in the Scumm options, but nothing seems to happen.

I have now filed a Wine bug. In case you are interested in following it or want to confirm that it happens to you too, stating your system information:

https://bugs.winehq.org/show_bug.cgi?id=46170

Are alternative player skins planned?

SLON wrote:

Are alternative player skins planned?

This was asked earlier and my opinion has not changed since:

As for skins support I don't think I will add it. I don' like the bloat such subsystems/libraries add even for the ones (e.g. me) who do not care skins. Also they can cause hard to resolve visual glitches and other subtle problems.

I have this error every time I star FSMP or exit the Settings menu.

Moderator, can we please pin this topic?

James-F wrote:

I have this error every time I star FSMP or exit the Settings menu.

You should check in Midiplayer's Device Settings dialog -> Recording Source -> Input port part what source/port is selected and if the selected one supports the required 44 kHz 16-bit stereo format.

1. If you have Primary recording driver selected in MidiPlayer (default) make sure that in Recording Devices control panel of Windows the default recording device is the right one and it supports the required format.
2. You can also try to select explicitly the right recording source/port in MidiPlayer's Recording Source combo list box.
3. You should also check if other programs do not use the recording source exclusively.
4. If none of the above helps you can press 'Del' in 'Input port' combobox to select none. Of course in this case normal recording will still not work but you will not get the warning message at startup.
You can still use recording when Bass output mode is enabled since Directsound capture is only required to record the sound of normal Midi Out ports (that is not rendered by FSMP).

Since when you get this error? New version of FSMP? (that would be strange since this part of the code has not been changed lately). Or new OS/driver update?
To tell you the truth I could not reproduce this problem on any of my installed OS (Win98, WinXP, Win 7, Win 10). The only situation when I get this warning is when using ASIO4ALL for recording.

You should download this latest test version to get a hopefully more informative error message.
http://falcosoft.hu/midiplayer_56_test.zip

I use a professional external audio interface set to 24bit 96KHz and have DAW software always running.
I do not have any problem with any other software/game that requires Direct Sound access for recording or playback.
Also, "Use Bass" for soundfonts in FSMP works fine in DirectSound or WAASPI in any samplerate.

James-F wrote:

I use a professional external audio interface set to 24bit 96KHz and have DAW software always running. I do not have any problem […]
Show full quote

I use a professional external audio interface set to 24bit 96KHz and have DAW software always running.
I do not have any problem with any other software/game that requires Direct Sound access for recording or playback.
Also, "Use Bass" for soundfonts in FSMP works fine in DirectSound or WAASPI in any samplerate.

According to error message this is not a format problem, but the very first call to DirectSoundCaptureCreate() fails. You get this error for all input ports? Without your DAW running?
In "Use Bass" state only the playback part of Directsound is used so it's not relevant here since this is a Directsound capture problem.
Not many games use Directsound capture (I know none).
The the other questions are also still relevant:

Since when you get this error? New version of FSMP? (that would be strange since this part of the code has not been changed lately). Or new OS/driver update?
To tell you the truth I could not reproduce this problem on any of my installed OS (Win98, WinXP, Win 7, Win 10). The only situation when I get this warning is when using ASIO4ALL for recording.

You can also try to reset FSMP settings 'Storage of settings -> Reset settings to default' (I do not think it can solve this problem, but it cannot hurt either).

Found what the problem was, I disabled all recording inputs in windows.
Enabling at least one, will not show the error in FSMP anymore.
I'd like to keep them disabled without getting the FSMP error please. 😀

James-F wrote:

Found what the problem was, I disabled all recording inputs in windows.
Enabling at least one, will not show the error in FSMP anymore.
I'd like to keep them disabled without getting the FSMP error please. 😀

I'm glad you have found the problem. You can disable the warning if recording and proper volume meter is not important for you (in normal Midi Out mode) the way I have already written:

4. If none of the above helps you can press 'Del' in 'Input port' combobox to select none. Of course in this case normal recording will still not work but you will not get the warning message at startup.

Thank you, it worked.

By the way in the new test version I have added DMX mus file (Doom engine) support. Testing/feedback is welcome.
http://falcosoft.hu/midiplayer_56_test.zip

In the new test version I have implemented a new Soundfont pre-loading/caching strategy.
In the Soundfont related part of Device Settings dialog there is a new section called 'Sondfont Loading'. Here can be found a new option called ' Preload referenced Instruments' (and also the previous Soundfont loading related settings such as 'Preload entire Soundfonts').
As the name of the new option suggests this strategy preloads the instruments/presets referenced by channels before playing.
Since Program 0 is almost always referenced implicitly by one of the channels the corresponding instrument/preset usually always loaded (if no explicit Program Change can be found then Program 0 is the default). So peloaded sample size can be higher than preliminary calculations may suggest.
This new option can be helpful in case of huge soundfont(s) since it can help to prevent stuttering without loading the entire soundfont(s) into memory (that can be time consuming and even impossible in case of the 32-bit version of Midiplayer).
Download location is the same as above.

@t9999clint:
This option can be especially relevant for your Sf2/Sfogg KOR soundfont.

Some quick testing shows that this does indeed solve the missing and skipping samples problem that happens when larger soundfonts are used, (Like mine and Strix's)
Thanks so much for this, now I can use my soundfont on my laptop again.

I'll let you know if I run into any more issues with this.