Spesek wrote on Today, 02:22:Hi Falco,
The new display looks great and thanks for the MIDI files!
However I believe I have found a bug in FSMP's seeking algo […]
Show full quote
Hi Falco,
The new display looks great and thanks for the MIDI files!
However I believe I have found a bug in FSMP's seeking algorithm.
When you load the "Idecs Hyper Groove / LATIN" (34H_Latn.mid) 88Pro demo song into FSMP, the seeking behavior is incorrect.
More precisely, the file enables phaser EFX at around 1:20 for the ending drum sequence. If you seek after this time, the EFX is not activated as it should.
Also, after it activates and you seek backwards (for example to 0:10),
the EFX stays on for the drums despite it not being enabled for most of the song when you play the file from the beginning.
It looks like FSMP ignores sysEx when seeking? What do you think?
PS: Regarding the patch names request, choosing a specific *.ins files for XG/GS is of course fine too.
Actually, would it be possible to extend this request to switching
to a specific VSTi for the system (syxg50 for XG and SCVA for GS), or is this too much? 😉
Hi,
1. Sending SysEx messages while seeking is disabled in FSMP deliberately. It's because some devices (mostly hardware but even some soft synths like Munt) have limited SysEx buffers and you cannot send large amount of SysEx data in a tight loop without risking complete freezing. Some Midi files contain hundreds of SysEx messages with the size of more than ~20KB. In such case even virtual Midi cables detect 'loopback error' and stop working.
In case of short messages FSMP filters out the redundant messages during seeking but in case of SysEx messages you would need full SysEx interpreters for all Midi systems to determine what is a redundant message. So you could only send all SySex messages during seeking. Some synths (e.g. my Dreamblaster X2) completely freeze and require a full restart when I try to do this.
Maybe some heuristics can be added that depending on the amount of SysEx messages enables/disables sending during seek time. This would work with your file since it has relatively few messages.
2. In the end 'Autoselect Patch names' resulted in some headaches because of logical inconsistencies. I had to disable software CTF while it is enabled. It's because so far when CTF was enabled the output device dominated and the Midi file's messages was altered to play properly on the output device according to the selected instrument definition. But now when 'Autoselect Patch names' is enabled FSMP cannot do this anymore since the Midi file (or selected Midi system) dominates and loads the linked instrument definition regardless if the output device is compatible with it or not. So 'Autoselect Patch Names' will be disabled by default and you also have to select 'Custom Patch Names' option explicitly to enable it. The configuration will look like this:
The attachment AutoPatchNames.jpg is no longer available
3. Yep, it's too much. It's because FSMP has to restart the whole engine when changing output device. And some Midi files contain multiple different SysEx resets so such restart would happen multiple times. Plugins like SC-VA requires more than 3 seconds to initialize so for many seconds the playback would stall. Not to mention that plugins require different sample rates, volume level, default reset mode etc. so simply changing the plugin during playback is not ideal.
But of course you can use completely fine tuned configurations with the help of Main menu-> Configuration presets. Then with the help of Ctrl + Alt + 'preset number' key combos you can switch between presets without even opening the dialog again.
@Edit:
BTW, I have also added the option to the context menu of Visualization dialog to use inverted colors which resembles more to the colors of the original LCD display:
The attachment invertedLCD.jpg is no longer available
New test version can be downloaded form here:
https://falcosoft.hu/midiplayer_66_test.zip
