@Kaminari:
Thanks for the report. At first I had not succeeded in reproducing the error since it only occured with an empty playlist (you forgot to mention). Now it's fixed.

@t9999clint:
Ok, I have added preset loading from command line. The syntax is: /preset x or -preset x where x is the preset number you specified as a postfix when you named the preset(the same way SysEx and shortcut works):
Re: Falcosoft Soundfont Midi Player

Also added Winamp invented *.MIZ file support (zip compressed midi) requested by MAN-biker.

http://falcosoft.hu/midiplayer_49_test.zip

Thanks Zoltan for the Program menu fix.

The preset hotkeys (ctrl+alt+num) don't work with the numeric keypad, is it intended?

Also, the instrument definitions are correctly changed when double-clicking a specific preset from the preset menu, but not when loading it via the hotkey shortcut.

Falcosoft wrote:

@Kaminari: Thanks for the report. At first I had not succeeded in reproducing the error since it only occured with an empty play […]
Show full quote

@Kaminari:
Thanks for the report. At first I had not succeeded in reproducing the error since it only occured with an empty playlist (you forgot to mention). Now it's fixed.

@t9999clint:
Ok, I have added preset loading from command line. The syntax is: /preset x or -preset x where x is the preset number you specified as a postfix when you named the preset(the same way SysEx and shortcut works):
Re: Falcosoft Soundfont Midi Player

Also added Winamp invented *.MIZ file support (zip compressed midi) requested by MAN-biker.

http://falcosoft.hu/midiplayer_49_test.zip

Ohhh.... that's what Phil did, I must have missed that in the video somewhere...

OK -preset works great now. Thanks. This is much cleaner than making entire separate folders for Midi presets.

The preset hotkeys (ctrl+alt+num) don't work with the numeric keypad, is it intended?

At first Shift+x shorcuts were added for VST effects but with Shift numpad keys do not work so I skipped examining numpad key's code. But apparently they work with Ctrl and Ctrl+Alt so I have added them now.

Also, the instrument definitions are correctly changed when double-clicking a specific preset from the preset menu, but not when loading it via the hotkey shortcut.

Yep, now it's fixed.
@t9999clint:
This bug also affected preset loading through command line so please re-download.

Moreover I have also added normal zip file support. Currently zips are treated like folders so only Drag&Drop works, they cannot be selected through openfile dialogs.
All playable files inside the zip are added to the playlist.

Download location is the same.

Hi Falco. Thanks for the test ver. Did you compile an x64 version by chance?

Hi,
no, not yet. The x64 version is actually a different branch (because of Win9x specific/unicode differences) so changes have to be transferred. So I usually do not make intermediate x64 test versions.

@citrixscu:
OK, here's the x64 test version for you to try:
http://falcosoft.hu/midiplayer_49_x64_test.zip

Thanks. Things seem to work fine. I have noticed Midiplayer sometimes “crashes” when switching ini via the preset menu from Munt to SC VA or back. Both configs load the Vst and associated settings file. The odd part is Windows reports that Midiplayer has crashed and wants to close the application, but Midiplayer remains open and works correctly. I’m running an Insider Preview version of Windows so it may be a Windows issue and not your application.

Unfortunately I could not reproduce your issue. What version are we talking about exactly? (x86/x64, 4.8 or 4.9 test).
Does this also happen when you use Ctrl+Alt+x shortcuts to change presets? Are there any differences between 4.8 and 4.9 test?
I have made some changes in the x64 version, so re-download it and try again.

@Falcosoft - Using the 4.9 x64 version from 07/08. I'll download your latest version and try out some things. Thanks.

Edit:
Back on production version of Windows 10 and no issues when switching between presets.

Hi -

I'm experiencing this issue with ScummVM games and Munt VSTi. It seems like it's playing the wrong instruments. In the linked video, I compare Munt VSTi to ScummVM's built-in Munt emulation. Seems to happen across multiple ScummVM games, but not DOSBox games.

Edit: Figured it out. Had to enable "True Roland MT-32 (disable GM emulation)" option in ScummVM. Or in the .ini, native_mt32=true

I'm glad you have found the problem.
In ScummVM there is a real bug but that affects GS devices not Munt VSTi.
MAN-biker and me had a conversation about this problem:

MAN-biker: Hi. Help me understand what happens, please. When i try to play "Leisure Suit Larry 6" game in SCUMMVM, using SCVA as […]
Show full quote

MAN-biker:
Hi.
Help me understand what happens, please.
When i try to play "Leisure Suit Larry 6" game in SCUMMVM, using SCVA as MIDI, I have "cutted" notes!
There is no this bug if i use, for example, internal windows GS emulator.
And there is no bug if i use DOSBox instead of SCUMM VM.

Me:
Ok, I think I have found the problem. ScummVM/Larry6 sets CC#75 to 0 on all channels. This controller is undefined in GM, but on GS devices it controls 'decay time' and its default is 64. So you should filter Controller 75 or set it to default 64 after larry/scummvm sets it to 0.
If you use FSMP:
1. Enable Main menu-> compatibility settings->'apply controls to midi in'
2. Select channel 10.
3. Set the 'User' controller number to 75.
4. Set it to 64, or press a reset.
5. Press the little 'force manul mode' button beside the 'User' controller.
6. Repeat 2-5 on all channels where you experience this cutoff effect.
---

Overall: On later GS devices (e.g. SC-8820/8850 and SC-VA) the Controllers 75-78 are defined ('Decay Time', 'Vibrato Rate', 'Vibrato Depth', 'Vibrato Delay')
and the default values for all these controllers are 64 (0x40h). Yet when ScummVM sends default controller values it sets these controller values to 0 on all channels. This can cause e.g. 'note cut off' bugs because of Controller 75 - Decay Time. For other GS or GM/XG devices where these controllers are not defined setting the values to 64 is just as harmless as setting them to 0. So there is no side effect and these controller's default values should be set to 64 (0x40h) instead of 0.

Edit:
This info can be useful for other software/Midi players as well. 😀 Man-biker wanted to send a bug report to ScummVM Issue Tracker, but I don't know if he did it.

Interesting. Have you posted a bug report about this on the ScummVM forums? You should do so if not.

Do you know, is there a way to set this value to 64 if I'm using savi host for SCVA? Also, do the instructions you gave for FSMP also apply to Munt VSTi?

Interesting. Have you posted a bug report about this on the ScummVM forums? You should do so if not.

Look at my edited post above.

Do you know, is there a way to set this value to 64 if I'm using savi host for SCVA? :

Man-biker has used it:

Also, do the instructions you gave for FSMP also apply to Munt VSTi?:

I don't really understand what you exactly mean but:
1. Munt(Vsti) is not affected at all either in MT32 or GM mode. (These controllers are not defined).
2. Of course you can do similar controller modifications with FSMP when you set its output to Munt Vsti.

Hi Zoltan,

I have two feature requests which I wanted to submit some months ago.

1/ Could FSMP support two MIDI ports (A and B) per device? As of today, the only player I know of that can properly do it is Fummy TMIDI. Dual port MIDI files are not common, but Konami has produced a fair number of them for their MIDI Power Pro collections, and they sound too awesome to be forgotten 😀

2/ FSMP supports switchable configurations via hotkey, which is really nice. Fummy TMIDI goes much further with a fully configurable device profile system, which can be switched on the fly according to specific keywords in the MIDI filename path. Once properly configured, you can pretty much double-click on any MIDI file and TMIDI will automatically use the correct synth you have set for a given profile (MT, GM, GS, XG, SC-55, 88Pro, 8850, whatever).

Another great point with this device profile system is that you can also assign several ports per synth -- not just two, but up to six!

TMIDI's parsing isn't based on reset messages, which are just too unreliable. The keyword system is not perfect, but it's a powerful tool which allows the user to have more control over the way the MIDI files are played. For example, if you know that a specific GM file has been authored on a GS or an XG synth, you can force the player to use the proper device just by mentioning [SC-55] or [MU50] (or whichever keywords you have customized in the player) in the filename or the folder name.

This is probably not an easy feature to implement, but it would make FSMP the definitive MIDI player. I can provide screenshots if you need more explanations.

1/ Could FSMP support two MIDI ports (A and B) per device? As of today, the only player I know of that can properly do it is Fummy TMIDI. Dual port MIDI files are not common, but Konami has produced a fair number of them for their MIDI Power Pro collections, and they sound too awesome to be forgotten 😀

I don't think it can be easily added. FSMP has no concept of more than 16 midi channels either in the engine or on the interface. So it would require a complete rewrite. Also I do not fully understand how it should work in case of 32ch midi files ( I have never met one before). I think the key is "port preference" Meta event (0x21) per tracks (at least in the file you have attached) but it seems to be very error prone since many sequencers/midi files use this event with arbitrary values.
So I think this remains a TMIDI exclusive feature 😀

2/ FSMP supports switchable configurations via hotkey, which is really nice. Fummy TMIDI goes much further with a fully configurable device profile system, which can be switched on the fly according to specific keywords in the MIDI filename path...
TMIDI's parsing isn't based on reset messages, which are just too unreliable. The keyword system is not perfect, but it's a powerful tool which allows the user to have more control over the way the MIDI files are played. For example, if you know that a specific GM file has been authored on a GS or an XG synth, you can force the player to use the proper device just by mentioning [SC-55] or [MU50] (or whichever keywords you have customized in the player) in the filename or the folder name.

I don't fully understand how this naming system exactly works but I do not think it would be ideal for FSMP if you add VST instruments and Bassmidi with different possible soundfonts to the equation.
The current system is also "fully configurable device profile system" but not standard midi port exclusive as TMIDI's. It also "allows the user to have more control over the way the MIDI files are played". You can force any Midi systems (GM/GM2/GS/XG/NX or custom SysEx) and the desired output synth. I do not know what more it should be capable of.
If you miss the "Once properly configured, you can pretty much double-click on any MIDI file and TMIDI will automatically use the correct synth you have set for a given profile",
it can be also simulated. Instead of renaming the files or put them in a special folder you can set the profile in the command line. So you can make a bat file, add one or more midi files and specify the profile (+optionally add the bat file to your existing prepared folder) :
E.g.

1@Echo off
2Midiplayer.exe midifile1.mid midifile2.mid /play /preset x

This method also does not require to associate .mid files with the player and you can use FSMP and TMIDI's method simultaneously without risking 2 naming systems to interfere with each other.

Falcosoft wrote:

I don't really understand what you exactly mean but:
1. Munt(Vsti) is not affected at all either in MT32 or GM mode. (These controllers are not defined).
2. Of course you can do similar controller modifications with FSMP when you set its output to Munt Vsti.

#1 was what I was wondering about. You're talking to someone who has a very surface-level understanding of all this.. So, thank you for breaking it down.

Falcosoft wrote:

Also I do not fully understand how it should work in case of 32ch midi files ( I have never met one before). I think the key is "port preference" Meta event (0x21) per tracks (at least in the file you have attached) but it seems to be very error prone since many sequencers/midi files use this event with arbitrary values.

Thanks for your answer. Rewriting FSMP from the ground up just for one feature doesn't seem worth it. And I'm not sure either how the two input ports are managed by such synths like the SC-88 or the MU80. Is it one device supporting 32 channels, or two 16ch devices stacked together?

For info, I just stumbled upon MIDI Trail, an open source visual player which also seems to be multiport compatible. I haven't tested it though.

And I'm not sure either how the two input ports are managed by such synths like the SC-88 or the MU80. Is it one device supporting 32 channels, or two 16ch devices stacked together?

I'm almost sure it's 2 separate devices since addressing 16+ channels is not possible according to MIDI standard and SMF specification.
Anyway my guess was right, both TMIDI and MIDI Trail use the "port preference" Meta event (0x21) to select which part to use. If you remove this meta event from tracks all tracks are played on the same part by both players. I have made a hack to support this multi-part midi files in case of bassmidi + soundfonts output. No standard midi/VSTi output support is possible currently.
In case of bassmidi + soundfont the situation is much less problematic since more than 16 channels are supported (right 16+ channels can be calculated with the help of port preference" Meta event). The interface and channel visualization do not represent these files properly, all the parts are combined to the one 16 channel domain, but playback should be right.
Please , test it with your other multi-part files.

http://falcosoft.hu/midiplayer_49_test.zip

Also in the mean time I have added some features:
1. Added zip file support (drag&Drop and from open dialog).
2. Added opening folders and zip files recursively (so supported files are added to playlist even from sub-folders);

It's not easy to tell how good it works because those Konami files were made for SC-88Pro, but I dusted off my good old Utopia Live soundfont (which I believe was partly GS compatible) and tried it with Salamander 2. The MIDI Channels Viewer only displays the first 16 channels, but the Event Debugger lists all 32 channels and I can properly hear the lead guitars from Port B. Not bad for a quick hack!