Does anyone know how to make shortcuts to configurations work? I noticed on Phils video he had a shortcut to MT55, Yamaha, Munt, etc. When I load a vsti I click save, and then click on the saved config file (associated with midiPlayer), it does not load the configuration saved in that file. Do I click "load at startup"? What about "use last configuration file"?

kolderman wrote:

Does anyone know how to make shortcuts to configurations work? I noticed on Phils video he had a shortcut to MT55, Yamaha, Munt, etc. When I load a vsti I click save, and then click on the saved config file (associated with midiPlayer), it does not load the configuration saved in that file. Do I click "load at startup"? What about "use last configuration file"?

Hi,
There are 2 different topics mixed up here (How VST/VSTi plugins work/How Configuration Presets work). First let's try the VST/VSTi part.
1a. If you want a VST/VSTi plugin to load when the player starts you simply have to check 'Autoload at Startup'. That's all, it speaks for itself. But if you only load the plugin at startup with this setting enabled the plugin will load with its default settings.
1b. In many VST/VSTi plugins there are multiple possible options that are different from default. If you want to save a custom state of the plugin you have to press 'Save' to save the current configuration of the plugin to an fxb file. If you want this newly saved state to be restored when the plugin is loaded at startup you should also select 'Autoload Last Used Settings File'. I hope it's clear for you know. These are explained in Phil's video rather clearly so I recommend to re-watch it if you still have problems to achieve VST/VSTi plugin and state loading.

2. In order to make shortcuts to work you should use so called 'Configuration Presets'. Configuration presets include the state of the player (including loaded VST/VSTi plugins among others).
You can save them in Main menu ->Configuration Presets.
This way you can save all the configurations you use and load them back when you want. You can also use configurations that do not use VST/VSTi plugins at all (but e.g. standard Midi out ports).
There are even shortcuts defined for easier loading of presets when you follow the naming convention described here:
Re: Falcosoft Soundfont Midi Player
So with Ctrl + Alt + P you can open the presets dialog or you can load a specific preset by Ctrl+ Alt + 'postfix number' (0 - 9).
For shortcuts to work you can set the preset's postfix number as a command line switch. E.g: "midiplayer.exe /preset 0"
More info about 'Configuration Presets':
Ways to make your MT-32 MIDIs sound right

Hi Falconsoft, thanks for your reply, and thanks for your great software 😀

So as I understand now, a configuration preset can define a plugin to be loaded at startup, but it's up to the plugin to restore it's own configuration through "Autoload Last Used Settings File". That seem like it will work well.

I have tried your MIDI player on my P166MMX with a Dream 9407 and a DB60XG in Win98SE and WinNT4.

It runs, but it is very demanding on the CPU.
If it shows only the main window, it takes about 25% CPU, with the green Note bars, it is already 95%.
When opening multiple files and it scans the MIDI files the GUI gets unresponsive until the scanning finishes. Scanning of the MIDI files seems to be slowed down by the above mentioned CPU usage. With full CPU usage also lagging of the playback is notable.

- Is it possible to priotorize playback as well as main player window GUI to keep it responsive?
- If you scan the MIDI files from the playlist, could you add an indicator in the playlist of what type the MIDI file is? (GM / GS /XG)
- For XMI files containing multiple songs it is good that the left/right song selector jumps within the file. Except that there seems to be not much indication. Would it it be better of such a multi song XMI file appears as multiple entries in the playlist? Like File_01.xmi;File_02.xmi a.s.o. with the sond length of the individual sub songs.
- I have seen in a few songs that the number of notes playing at the same time exceeds 250 ?!?

Hi,
1. 166 MHz CPU is definitely not ideal for Midi player. Midi Player is rather for newer CPUs (ideally at least dual core) in the GHz range. The weakest hardware I use for testing and gives acceptable result is Athlon 550 MHz in Win98SE. The Midi file scanning already uses its own separate thread but in the end this thread has to be synchronized with the main GUI thread for displaying the result of the scanning in the playlist. Handling threads is inferior in Win9x compared to NT line but as I said it works without problem in Win98SE with at least an 500 MHz CPU. The green 'Channel' displaying also uses its own separate animation thread and you can decrease the animation frequency by right clicking on the channel display window and selecting FPS->30 instead of the default 60 FPS. This should reduce CPU usage significantly. Also I have noticed that some Chipset/VGA card and desktop bit depth combinations can result in unusually low performance so you should try different desktop bit depths (16/24/32 Bit). In older versions of the player the green Channel display used 8-bit bitmaps bit it has been changed to 32-bit in newer versions for better font smoothing. This can be more demanding for older hardware despite the fact that the visualization/display routine uses hand optimized fast assembly code.
2. The Midi system used by a Midi file (GM/GS/XG) is detected when the given file is loaded for playback and displayed at the left hand side of the black display area. Scanning for this information in the playlist processing phase would slow down the scanning process very much.
3. I do not like this idea of separating XMI segments as virtual files for several reasons. One is the handling of loop points between segments, the other is the problem of seamless playback of the consecutive segments.
4. Of course it's possible. There are so called black midi files that can contain several hundred/thousand Note events per seconds. But there are also not so well programmed Midi files that fail to send proper Note Off messages and also Midi files that use excessive amount of Hold/Sustain pedal messages. If you can upload/attach some of these files I can tell you the exact reason.

@Edit:
1. You can also try to disable the constant Directsound recording thread (that is necessary for the Volume meter display in case of normal Midi out ports) by pressing the minus sign in Device Settings dialog -> Recording Source -> Input Port.
2. I will look at the code tonight. Maybe detecting the Midi system at scanning time can be added with relatively little overhead.

Here's a new test version for you to try:
http://falcosoft.hu/midiplayer_58_test.zip
The last column of the playlist now also displays the Midi mode of the file such as GM/GS/SC88/XG/MT32/NX. Notice that there are 2 kinds of 'GM' mode corresponding the grey vs black GM sign.
The grey/lower case GM means that no real GM ON SysEx is detected but without any explicit SysEx found the Midi file is handled/treated as a 'genaral' midi file.

Thanks for the quick response. The midi file type indicator helps me a lot in sorting out my midi files.

The recording thread disabled saves about 20% CPU on the P166MMX. So just playing with the main window open keeps the CPU at 4 - 5%.

The hint that you use 32 bit bitmaps for the bars was useful. I was running 1280x1024 at 16 bit color depth on the Riva128 and now I changed to 1024x768 at 32 bit. Result: at 30 fps bar display CPU is at 35% while playing (Recording OFF) and at 50% when going up to 60 fps. This is a huge difference to the 16 bit mode. Maybe recommend a 32 bit graphics mode for low end systems to prevent bit depth conversion. You can also add NT4 to the tested OS.

As for the XMI segments, I think it is just currently not so easy to see, when there are segments selectable.

Hi,
1. I'm glad that it can work with these compromises on your system.
The problem with a 'use 32-bit desktop bit depth for better performance' recommendation is that it's not universally true. E.g. on My Athlon XP + Abit KT7A (VIA Chipset) + Geforce 6600 PC the situation is just the opposite. It produces horrible results with 32-bit bitmaps in 32-bit desktop mode. 16-bit desktop modes are much faster with all software that uses 32-bit bitmaps.
2. Actually NT4 is an OS that cannot be supported because of the lack of higher DirectX versions. E.g. Bass/Bassmidi libraries cannot be loaded at all so all advanced features (Soundfonts/VST plugins/EQ etc.) are unavailable on NT4. Testing on NT4 is near pointless since NT4 is not supported. Even Win95 is better in this respect.
3. I will try to find out something later.

May I ask how Bassmidi + Soundfonts and/or VSTi plugins work with your P166 MMX?

I got a k6 system with a cpu speed I can change around, you want me to test midiplayer at any specific speed? (80-450mhz)

t9999clint wrote:

I got a k6 system with a cpu speed I can change around, you want me to test midiplayer at any specific speed? (80-450mhz)

Hi,
Thanks for your offer. Honestly for me it's not so important but for others it can be informative. So if you have the time and mood e.g. a K6-300 result is more than welcome.

Hello,
I am using the midi player on an Intel NUC and it runs perfectly. Now I saw that the Raspberry Pi 4 is out. I was wondering if the midi player would perform faster now in wine. I have no experiences with this tiny thing, but 4gb of RAM and I think about 60 or 80 percent more CPU power sounds like an emulation improvement to me. Any thoughts on that?

Something in addition: I've seen that Windows IOT can be installed on a pi. Will the midi player run on Windows IOT?

Lazar81 wrote:

Hello,
I am using the midi player on an Intel NUC and it runs perfectly. Now I saw that the Raspberry Pi 4 is out. I was wondering if the midi player would perform faster now in wine. I have no experiences with this tiny thing, but 4gb of RAM and I think about 60 or 80 percent more CPU power sounds like an emulation improvement to me. Any thoughts on that?

Something in addition: I've seen that Windows IOT can be installed on a pi. Will the midi player run on Windows IOT?

Hi,
1. I have no definitive answer since I have no Raspberry Pi 4 to test with. But I do not think using Midi Player with standard midi out ports or reasonable sized soundfonts could cause any problems even on a Raspberry Pi 3. But using VSTi plugins, especially Munt VSTi in floating point mode can be problematic (even for weaker x86 systems).
2, AFAIK Windows 10 IOT cannot run native x86 Win32 desktop applications but only UWP apps. If this is true then neither Midi Player, Munt, SAVIHost nor any VSTi plugins (SC-VA, S-YXG50, Munt VSTi) can work on Windows 10 IOT.

Yup. FSMP would require Wine on a Pi 4, and this would require x86 multilib functionality. It's possible, but the absence of hardware instructions to accelerate this will cripple performance. Apparently Qemu on a Pi 2 provides the rough equivalent of a 300mhz P2, and that's simply not enough for many software synthesizers.

If you want to run FSMP, there are many Atom based SBCs and mini PCs which will do quite nicely.

If you really want to run a soft synth on Pi there is already MUNT and FluidSynth for it, and if you have a decent two-way USB MIDI interface cable then you are already set up with all you need.

The BASSMIDI library apparently can be obtained for ARM somehow, because otherwise I don't see how that softsynth could possibly exist in droidsound-e for Android.

Perhaps under license from the original author.

gdjacobs wrote:

Perhaps under license from the original author.

You can just download them from https://www.un4seen.com/bass.html. It says "BASS is also available for ..." and links to downloads for the various ports.

Excellent. That's relatively new.

Last I checked they didn't port Bassmidi yet. BUT that was a year ago, now it looks like it's there.
I'm totally adding this to my WavePi project, I don't like fluidsynth at all.

Also, it's reached the point where if you want to run munt and sf2 files on a rasp pi, you're better of trying with my WavePi project, it even listens to the same sysex messages for profile switching.
WavePi: Use Raspberry pi (2/3/4) as a AIO MIDI synth

That being said If you can use a system is fast enough to run MidiPlayer, it's a far better idea to just use that, even on linux it's way better at this sort of stuff than my project is. (just making sure people know that I'm not trying to compete or anything)

t9999clint wrote:

Last I checked they didn't port Bassmidi yet. BUT that was a year ago, now it looks like it's there.
I'm totally adding this to my WavePi project, I don't like fluidsynth at all.

How? There's nothing like Fluidsynth for BASSMIDI (meaning something you can send MIDI events through ALSA.)