Roland User wrote on 2024-02-13, 01:24:

I want ask something else on WinMM Multi Port VSTi ) now this plugin if I selectin MIDI device , I see this as on first attachme […]
Show full quote

I want ask something else on WinMM Multi Port VSTi ) now this plugin if I selectin MIDI device , I see this as on first attachment ) if you remember I asked as use VBS scripting to recive MIDI ID device. I think what if recive MIDI ID from your plugin ? )
Please if this not hard add in this plugin MIDI device ID near with MIDI device name ) this will make it easier on set force MIDI ID Set for WMP )
I offer do make as second attachment
Maybe you will consider this idea )

The listed Midi Out devices are already in deviceId order (not in alphabetical or anything else). The deviceIds starts from o and ends with device count - 1.
That is: 0, 1, 2, 3, 4, ... deviceCount-1
So you can already use the list to find out the device Ids of listed devices.
Be aware that the list of 32-bit and 64-bit devices can differ on 64-bit Windows. On 64-bit Windows the default WMP is also 64-bit so you need the list of 64-bit devices (that is you should use the 64-bit plugin as help).

Thank you ) this made it easier me task easy )
For me was very hard understand as reciv device ID , that's why I was very puzzled as set WMP MIDI Reseter ) I maybe slightly stupid ) because had tried what not need )
My requests vbs scripting not worked if I do reinstall Windows )
Cause why me need forced WMP to set MIDI Device ID is that at every run Cakewalk 9.0 be losting MIDI Device ID for WMP and automaticaly reset to default Microsoft GS Wavetable Synth
And to requiesting Device ID I used very very strange decision , I launching DOSBOX and input message mixer/ listmidi

Falcosoft wrote on 2024-02-13, 02:30:

Be aware that the list of 32-bit and 64-bit devices can differ on 64-bit Windows. On 64-bit Windows the default WMP is also 64-bit so you need the list of 64-bit devices (that is you should use the 64-bit plugin as help).

How much I known , if I use VST Devices based on LoopMIDI , list for both version players be identificly ) and list devices will be diffirenced only if have records
HKLM\Software\Wow6432Node\Microsoft\Windows NT\CurrentVersion\Drivers32\midi
and
HKLM\Software\Microsoft\Windows NT\CurrentVersion\Drivers32\midi
if here there is lists of midi - midi , midi1-midi9 or something like that list diffirence but if use LoopMIDI , listing was united )
or I something not known ?

Roland User wrote on 2024-02-13, 08:35:

How much I known , if I use VST Devices based on LoopMIDI , list for both version players be identificly ) and list devices will […]
Show full quote

Falcosoft wrote on 2024-02-13, 02:30:

Be aware that the list of 32-bit and 64-bit devices can differ on 64-bit Windows. On 64-bit Windows the default WMP is also 64-bit so you need the list of 64-bit devices (that is you should use the 64-bit plugin as help).

How much I known , if I use VST Devices based on LoopMIDI , list for both version players be identificly ) and list devices will be diffirenced only if have records
HKLM\Software\Wow6432Node\Microsoft\Windows NT\CurrentVersion\Drivers32\midi
and
HKLM\Software\Microsoft\Windows NT\CurrentVersion\Drivers32\midi
if here there is lists of midi - midi , midi1-midi9 or something like that list diffirence but if use LoopMIDI , listing was united )
or I something not known ?

LoopMidi installs itself as both 32-bit and 64-bit driver on 64-bit Windows.
But the potential difference has nothing to do with LoopMidi. If you have 32-bit only drivers installed (e.g. Midi-Yoke, Maple etc.) or 64-bit only drivers (I do not know if such driver exists) your lists will be different regardless of LoopMidi. 32-bit Midi software will also see the 32-bit only drivers but 64-bit Midi software will not and vice versa.

But both WMP version read this key in registry : HKCU\Software\Microsoft\ActiveMovie\devenum\{4EFE2452-168A-11D1-BC76-00C04FB9453B}\Default MidiOut Device\MidiOutId How much I known , very small programs which read in 64 bit system only one How much I known , very very little programs which read in 64 bit system only one branch registry and use only device from one branch ) although yes , it happens that device can only recorded to one registry branch )

Roland User wrote on 2024-02-13, 15:49:

But both WMP version read this key in registry : HKCU\Software\Microsoft\ActiveMovie\devenum\{4EFE2452-168A-11D1-BC76-00C04FB9453B}\Default MidiOut Device\MidiOutId How much I known , very small programs which read in 64 bit system only one How much I known , very very little programs which read in 64 bit system only one branch registry and use only device from one branch ) although yes , it happens that device can only recorded to one registry branch )

AFAIK, on 64-bit Windows there are 2 such keys:
32-bit: HKEY_CURRENT_USER\Software\Microsoft\ActiveMovie\devenum\{4EFE2452-168A-11D1-BC76-00C04FB9453B}\Default MidiOut Device
64-bit: HKEY_CURRENT_USER\Software\Microsoft\ActiveMovie\devenum 64-bit\{4EFE2452-168A-11D1-BC76-00C04FB9453B}\Default MidiOut Device

And under these keys usually not all legacy Midi drivers are listed but just ones that are registered in the system as virtual devices (not all virtual Midi ports do/did this).
As you can see Midi-Yoke (32-bit only driver) is not listed under either of the above registry keys yet normal 32-bit Midi clients can use it.

And as you can also see LoopMidi is actually turned off (by closing the LoopMidi client and stopping the service, but it is still installed) yet it is still listed under the above registry keys but none of the Midi clients can see/use it (since it is really not available).
So if WMP really uses these keys it's a rather sloppy detection that cannot work properly many times.

Overall these 2 registery keys list the "properly installed Midi Out devices" and not the currently available Midi Out ports on the system. These 2 states usually are the same but as you can see sometimes can differ.

Hi,

is the FPU heavily used by Soundfont Midiplayer, is a strong FPU important ?
Are these CPU flags used by Soundfont Midiplayer:
CMOV
SSE
SSE2

Speed difference RAM:
512Mb to 2 Gb
1 Gb to 4 Gb
or is 1 Gb just enough ?

Rolandradio wrote on 2024-02-18, 18:59:

Hi, […]
Show full quote

Hi,

is the FPU heavily used by Soundfont Midiplayer, is a strong FPU important ?
Are these CPU flags used by Soundfont Midiplayer:
CMOV
SSE
SSE2

Speed difference RAM:
512Mb to 2 Gb
1 Gb to 4 Gb
or is 1 Gb just enough ?

Hi,
1. Midi Player itself only needs an FPU so no CMOV or SSE/SSE2 is required. But the latest BassMidi library requires SSE and so implicitly CMOV too.
I asked Ian to make the last non-SSE version of BassMidi available so the next 6.3 version of Midi Player will only require an FPU (this was the case before version 6.2).
https://www.un4seen.com/forum/?topic=20258.ms … 41698#msg141698

2. The player itself is not too FPU heavy but some VSTi plugins like the integrated Munt VSTi in floating point mode is.

3. The player itself works perfectly even with a PC with 64MB RAM. This is even true when Bass/BassMidi is activated.
But of course the RAM size limits the max size of the SF2 soundfonts you can use . With a reasonable sized SF2 (~32 MB like the one you can download from my website) there is no difference between 512 MB or 1 GB/4 GB RAM.

Perfect answer !

Soundfont Midi Player is great in comparison of today's big software, even under Linux with Wine (windows emulation) its running fast on older PC's.
Works also with the CPU VIA C3 1000MHz VIA Epia-PD but with samplerate output Bassmidi max 22KHz its just fast enough.

Usually higher better ) as far as I know Zoltan tried maximum use standard x86 comands in code , aslso I know what Zoltan created only MUNT with use as x86 and as SSE commands )

The efficiency of software, small but can almost do what other big programms (big HDD space needed, fast CPU needed).
Zoltan tried maximum use standard x86 comands in code = do you mean CPU optimized ?

Last thing:
Is MMX important for Soundfont Midiplayer , MMX and non-MMX difference ?

Rolandradio wrote on 2024-02-25, 19:29:

The efficiency of software, small but can almost do what other big programms (big HDD space needed, fast CPU needed). Zoltan tri […]
Show full quote

The efficiency of software, small but can almost do what other big programms (big HDD space needed, fast CPU needed).
Zoltan tried maximum use standard x86 comands in code = do you mean CPU optimized ?

Last thing:
Is MMX important for Soundfont Midiplayer , MMX and non-MMX difference ?

No, MMX is not required and the player has no optimization for MMX either.

I see the new driver version somewhat improves support for the S-YXG2006LE VSTi. Does it have any advantages over the XG50 regarding sound quality? (The soundbank is 3x as large, at least.) Its XG capabilities are reduced AFAIK, which is however rather irrelevant for gaming purposes. How to set it up to launch in GS mode by default?

Trelokk wrote on 2024-02-28, 07:40:

I see the new driver version somewhat improves support for the S-YXG2006LE VSTi. Does it have any advantages over the XG50 regarding sound quality? (The soundbank is 3x as large, at least.) Its XG capabilities are reduced AFAIK, which is however rather irrelevant for gaming purposes. How to set it up to launch in GS mode by default?

Hi,
I'm not sure if you deliberately asked this question here (FSMP topic) or just accidentally and your question is actually VST Midi driver related.
Anyway, the situation with S-YXG2006LE is exactly as you described: it has better samples but worse effect engine implementation (insertion effects are completely missing). Also the implementation of default drum channel 10 in XG mode differs from S-YXG50 and is less compatible. In case of S-YXG50 channel 10 in XG mode is always a drum channel while in case of S-YXG2006LE any bank select MSB message that is not bank MSB 127 makes it a melodic channel. Since many GS Midi files send Bank MSB 0 to channel 10 this can cause piano instead of drums problems.
Since S-YXG2006LE is such a plugin that cannot save/load its settings you can set S-YXG2006LE to GS mode the same way in VST Midi driver and in FSMP: select GS reset as actual reset SysEx. In case of the new VST Midi driver (from v2.3.0) selected reset SysEx messages are sent when the driver is started. FSMP always worked this way.

Yeah, I was erroneously assuming this was the VST Driver thread. My apologies. Anyway, I guess one could at least test the 2006LE with the new release. Whether it sounds better than the XG50 is a different matter, but since pretty much none of the classic games (Doom, Duke3D, Descent etc) go beyond GM standards, in theory it should be ok for gaming purposes.

A fully portable LE plugin with optimized settings would be interesting, but I guess only Evgeny could make it happen. That or some hacked XG50 version which could utilize the larger soundbank. If it's really a significant improvement, that is.

A community-made hacked XG synth was put together for the XG enthusiast community, according to other XG threads here, but it's not distributed openly, so I have no first-hand experience with it or much knowledge beyond what I glimpsed in the vids posted here.

Trelokk
You not need versions of S-YXG50 / YMF-724 / S-YXG2006Le , if you want very good sound , you need find TyRUS or Vampire synthesizers ) this - best of what on AWM engine which was be integrated in proucts DB-50 and S-YXG50 / S-YXG100 / YMF-724

Roland User wrote on 2024-03-20, 22:45:

Trelokk
You not need versions of S-YXG50 / YMF-724 / S-YXG2006Le , if you want very good sound , you need find TyRUS or Vampire synthesizers ) this - best of what on AWM engine which was be integrated in proucts DB-50 and S-YXG50 / S-YXG100 / YMF-724

I do not know Vampire but for me the size of the TyRUS bank (~800 MB) is not justified compared to the 4 MB of S-YXG50 and ~10 MB of YMF-724 / S-YXG2006LE.
I do not hear that TyRUS sounds 80 times better 😀.
Actually in this respect my personal favorite is still S-YXG50. It is the least buggy and has the best quality, feature set, performance / size ratio.

I know this is a tricky request but is the codebase compatible to be ported to Linux ? I'm not sure if MidiPlayer use QT for GUI if it's QT or GTK I guess we have a decent chance to port it to Linux.

Linux sadly, currently doesn't have a good Midi Player which is sad, I'm enjoying Linux but the lack of a great player really makes me feel a bit uncomfortable whenever I want to listen to MIDI music.

OutlawHusbando wrote on 2024-03-25, 13:12:

I know this is a tricky request but is the codebase compatible to be ported to Linux ? I'm not sure if MidiPlayer use QT for GUI if it's QT or GTK I guess we have a decent chance to port it to Linux.

Linux sadly, currently doesn't have a good Midi Player which is sad, I'm enjoying Linux but the lack of a great player really makes me feel a bit uncomfortable whenever I want to listen to MIDI music.

Unfortunately no.
MidiPlayer uses neither QT nor GTK. It is not even written in C/C++ but in Object Pascal/Delphi. It also calls Windows functions directly (e.g. WinMM functions) that are not portable at all.
FSMP started as a hobby project for myself (and for my SB Live!) about 20 years ago. Multi-platform/open source compatibility was not a concern then.
But according to my experience and the feedback of many others MidiPlayer works absolutely fine under Wine.