After reading everyone's opinions on VST's, I finally made the move from using Soundfonts via VirtualMidiSynth, and I must say, I am really happy with the outcome.
It all sound great! The player is fantastic as a VST host. I have SCVA, S-YXG50, MUNT, and Arachno SoundFont all setup individually with their own virtual midi port.

Took me a few hours to get everything setup and sounding good. This would have taken days without Phils posts and videos.

If it would be possible, I would really welcome a feature to start the multiple instances with Windows login, and in the background. That would be the icing on the cake.

Hi,

If it would be possible, I would really welcome a feature to start the multiple instances with Windows login, and in the background. That would be the icing on the cake.

What prevents you from doing this? Starting programs at Windows start is a standard feature of Windows for a long time. You can do this many ways (Startup Folder, Task Scheduler etc.). To start FSMP loaded into system tray you can use the /tray command line switch.
Also a better option compared to Phil's method in his video (make separate copies of FSMP) to handle multiple configurations is using 'Configuration Presets':
Re: Falcosoft Soundfont Midi Player
You can also use the command line switch /preset x (x is the preset number).
So e.g. in task scheduler you can start a batch file at logon containing something like:
Midiplayer.exe /preset 1 /tray
Midiplayer.exe /preset 2 /tray
....

To tell you the truth I don't really understand what is the advantage of using multiple instances of FSMP listening on different midi ports instead of using one instance and port and switching configurations real time. Have you seen this?:
https://youtu.be/6CdJ7sEt8UM

^Awesome. I did not know this.

Will mess around with it all again tomorrow.

Falcosoft wrote:

@Edit:
Here's the corrected file:

SUNNYDAY_corrected.zip

Thank you for your help.

Yesterday i've received MU-2000, and the first thing i've done has been some test and comparison with yamaha syxg50 and 200. Then i've started to recording, but I've had a problem:

I'm Using final fantasy VII XG Midi File, overriding loopcount and setting loopcount to 1 (this worked fine when i recorded FFVII songs with softsynth). Now, when i use USB midiport to my MU-2000, when the loop should start it stop playing and nothing more happens. Even if i'm not recording, If i'll try to recording, files remain locked and nothing more happens. It could happens that loops works fine but for example on track 3: Makou reactor i've not been able to have this working). Btw after I start software and playback after a first song, reproduced in the right way the second songs stop after the first loop.

I've recorded a small song because i've noticed that when loop works, there's a lag bug. I've attacched 2 files, of a short song (always ff7) so that you could hear what i'm talking about. Bug is in the mu2000 version.

Thank you for yout help.

Aldo

I've recorded a small song because i've noticed that when loop works, there's a lag bug. I've attacched 2 files, of a short song (always ff7) so that you could hear what i'm talking about. Bug is in the mu2000 version.

The 'bug' is that your hardware unit is slower than soft synths. When the loop start point is in the middle of a file many messages (except Note On/Off) have to be sent till that point to get the proper state for playback. For seamless loops faster processing is required. I don't think I can do anything about this.

Now, when i use USB midiport to my MU-2000, when the loop should start it stop playing and nothing more happens. Even if i'm not recording, If i'll try to recording, files remain locked and nothing more happens. It could happens that loops works fine but for example on track 3: Makou reactor i've not been able to have this working).

Maybe this problem is also related to interface/unit speeds since I could not reproduce it.
You have to help me to find out what the problem is: first load your mentioned problematic song, (Makou reactor) open Event Viewer/Debugger and delete the 'LoopEnd' meta marker event from the 1st track. Then save/reload the file and try to play again. Report back if the loop is played right this way.

Falcosoft wrote:

The 'bug' is that your hardware unit is slower than soft synths. When the loop start point is in the middle of a file many messages (except Note On/Off) have to be sent till that point to get the proper state for playback. For seamless loops faster processing is required. I don't think I can do anything about this.

How exactly are loops implemented in MIDI then?
It's not enough to just jump back to a given position in the track (leaving the responsibility for the playback state to the MIDI file itself, setting it just before the loop)?
You basically have to replay all non-note data from the start of the file to the loop point, to make sure all instruments, SysEx etc commands are sent, so it plays from that position as it would have on the first play?

I think I have some options wrong.

When I play a midi through the player, or run an eternal game using it, the SC-55 sounds tinny on the next file. I have to hit the players reset to get some oomph back to the sound, or restart the VST to automatically load the saved preset.

Munt does this too, but the Yamaha S-YXG50 does not seem to have a problem.

My settings:

Scali wrote:

How exactly are loops implemented in MIDI then?
It's not enough to just jump back to a given position in the track (leaving the responsibility for the playback state to the MIDI file itself, setting it just before the loop)?
You basically have to replay all non-note data from the start of the file to the loop point, to make sure all instruments, SysEx etc commands are sent, so it plays from that position as it would have on the first play?

Since loop support in SMF files is not standardized there are no rules or even best practices that all looped midi files must follow. I have already met looped midi files where volume, reverb level and other controllers are not in the same state at the loop end point as at the loop start point. So to be on the safe side yes, FSMP essentially 'plays from that position as it would have on the first play'.
Maybe the official midi files from games are more optimized so this is not necessary in all cases. After all this could be another compatibility option 😀

brad86 wrote:

I think I have some options wrong.
When I play a midi through the player, or run an eternal game using it, the SC-55 sounds tinny on the next file. I have to hit the players reset to get some oomph back to the sound, or restart the VST to automatically load the saved preset.
Munt does this too, but the Yamaha S-YXG50 does not seem to have a problem.

FSMP always send the reset SysEx message you have selected (by right clicking the Reset button) before playing next file. I have checked and it works good. According to the Midiplayer.ini you have attached you use the LoudMax VST plugin. I think the phenomenon you experience can be related to some 'intelligent learning' feature of LoudMax. Try to test again without LoudMax.
The difference between SC-VA/Munt and S-YXG50 can be attributed to the very different default volume level of these plugins. Contrary to SC-VA/Munt S-YXG50 is so loud by default that LoudMax has nothing to do.

Hum, right...
So I suppose you could have two modes:
1) Just loop, and assume that the song handles the state
2) Make sure that the state is correct

Mode 1) would ensure that the looping has no delays, and I would use that as the default.
Mode 2) poses some interesting optimization options.
I would say that for all the standard/GM/GS/XG MIDI commands, you could implement a state cache so you know what the state should be at a given point.
That is, only the last value of each known command will 'stick', eg program change, control change etc.
So for all those commands, you could just precalc the state and send one command for each, which should be pretty seamless still (especially if you filter out unused MIDI channels, controllers and such).
Let's call this 2a).
Then I can think of a 'safe mode', let's call it 2b).
This mode is basically a combination of mode 2a), as in, all known standard commands are cached and filtered... but all the unknown ones (SysEx stuff and/or other commands where you don't know if only the last sent command has effect on the status) will be cached and sent as well.

In all cases you could precalc these states at the start of playing, so anytime the loop comes, you have an optimized minimal set of commands to send.
Then you can let the user choose between the three modes of loop compatibility.

@Scali:
There is already some kind of optimization/state cache implemented. Without it not only loops but seeking itself would be problematic, since later tracks that might use the same channels as earlier ones could overwrite the right values for a given seek end position while iterating events in track order.
So I think at the moment I'm going to add only a 'just loop' option.

RetroGC:
I have added a new option to Loop Settings dialog: 'Just loop, assume correct state'. If enabled FSMP does not send messages to assure correct controller, program etc. states at the loop start point so it is much faster. Try loops on your HW with this setting enabled.
http://falcosoft.hu/midiplayer_53_test.zip

Falcosoft wrote:

RetroGC:
I have added a new option to Loop Settings dialog: 'Just loop, assume correct state'. If enabled FSMP does not send messages to assure correct controller, program etc. states at the loop start point so it is much faster. Try loops on your HW with this setting enabled.
http://falcosoft.hu/midiplayer_53_test.zip

Just downloaded!
Now i've no more crash, every song loop but I've still Lag.
I'm going to register and upload a track.
Aldo

Here fanfare track, with the lag. at about 23 sec. ca.
Now software works fine, i mean no more crash with external synth, btw there's still lag.

Aldo

Hi,
Sorry, I have no other idea what else to change. But to tell you the truth I do not hear the lag either 😀 Please, make a record of the attached midi instead. I know how this should sound at the loop point.

Falcosoft wrote:

Hi,
Sorry, I have no other idea what else to change. But to tell you the truth I do not hear the lag either 😀 Please, make a record of the attached midi instead. I know how this should sound at the loop point.

XG - 1-10 Fighting.zip

HI,
first of all thank you for your support. Meanwhile i've done a step ahead, and i've been able to install Yamaha USB to Midi Driver for this hardware and so I'm no more using USB-To-Midi.

I've done the recording without fastloop and with fastloop, and with fast loop, now it play smooth.

I would like to ask, when is an usb cable plugged to the external synth and no an usb-to midi cable which are the best settings to configure in the Maximum Sysex Chunk Size and Delay Between Sysex Chunk? NOw, with an USB cable from PC to MU-2000 EX i've selected 1024B / 10ms.

With the standard Loop setting btw, there is a small lafg even with usb cable, se that compatibility settings, it's a really usefull compatibility setting.

Aldo

P.S.: I'm going to test soon even if i can plug Roland Studio Canvas SD-50 and have this hardware work with USB Cable (until now everything i've recorded and uploaded on youtube was midi file without loop and with standard USB-TO-Midi file it worked good).

Yeah, I also hear the 'fastloop' version to be problem free.

which are the best settings to configure in the Maximum Sysex Chunk Size and Delay Between Sysex Chunk? NOw, with an USB cable from PC to MU-2000 EX i've selected 1024B / 10ms.

There are no objective best settings. Bigger chunk size and smaller delay mean faster transfer speed. The faster the better while it's problem free (i.e no SysEx buffer errors or other audible side effects). Though 10ms latency is rather on the 'soft synth compatible' side of the scale. Many hardware require about 50ms for processing reset-like SysEx messages. But as I have said if it works for you then use it.

HI,
sorry for bothering. Today I've noticed on a osundtrack I've recorded, that droms was a little stranger, so i've tryed to change, but on channel 10 i don't see drum maps anymore. So I've tried to use custom patches GM1 and 2 but I don't see anymore drums so that i can change drummap.
What I've to do to see again drums in progam?
Thank you.
Aldo

Hi,
I don't really understand what your problem is (maybe an attached picture could help). So I can only tell what the situation is with drum channel(s)/Midi systems in general.
Channel 10 as a drum channel is only guaranteed in GM. In GS the default (after a GS Reset) is the same as in GM but SysEx messages can change this so any channels can become a drum/melodic channel.
In XG all channels can be a drum channel by setting Bank MSB to 127 (but the default channel 10 is treated as Drum channel by some implementations even without setting Bank MSB to 127) . In GM2 the situation is similar to XG but you have to set Bank MSB to 120 instead of 127.
In Main Menu->Instruments selecting 'Built-in GM Patch Names' always treats channels 10 as Drum channel. If you select Main Menu->Instruments->Custom Patch Definitions... make sure you select the appropriate definitions for melodic and drum channels (they are usually separate ones for GM/GS/XG).