Falcosoft wrote on 2024-10-05, 06:41:

Hi, I used S-YXG50 VSTi for the investigation since its user interface helps to understand what is happening. When you use FSMP […]
Show full quote

Meowdori wrote on 2024-10-04, 17:37:

Hey, it's been a long, long while since i last wrote here, but today an interesting case of inconsistent playback between few di […]
Show full quote

Hey, it's been a long, long while since i last wrote here, but today an interesting case of inconsistent playback between few different MIDI players caught my attention. I can't seem to be able to pinpoint the cause, so any help solving this issue would be appreciated.

One of the Yamaha XG demo songs (see the attachment) plays pretty much the same in FalcoSoft MIDI Player, in MIDITrail and in old Winamp 2.91, with one exception being TMIDI.

The actual differences i've spotted, together with their timestamps are as follows:

- [1:03] - Drum fills sound different (bongos) in TMIDI (starting from that moment, they repeat several times throughout the track)
- [2:32] - Different and stronger snare is only audible in TMIDI

Does anyone have any ideas on what might be causing this inconsistent playback behaviour and which one is the correct sounding of the track?

Hi,
I used S-YXG50 VSTi for the investigation since its user interface helps to understand what is happening.
When you use FSMP you can also use its 'Midi Channels' visualization dialog to follow my explanation.
Your Midi file uses 2 drum channels: 10 and 11. Channel 10 is set to Rock Kit and Channel 11 to Analog Kit by the Midi file.
When your timestamped parts start you can notice on both FSMP's Midi Channel display and on S-YXG50's channel display that both channel 10 and channel 11 are active.
Contrary, when you use TMIDI you can notice from the start that it falsely identifies channel 11 as a melodic channel -> 'Acoustic Guitar (steel) -BK 127',
and when your timestamped parts start you can notice on S-YXG50's channel display that only channel 10 is active, you cannot see any activity on channel 11.
Yet, the notes on channel 11 are audible but they are sent by TMIDI to channel 10 !
It seems that TMIDI sends all drum related notes to channel 10. But the problem is with this approach is that channel 10 and 11 use different drum kits, so when channel 11 notes are sent to channel 10 by TMIDI then you get different sounds.
The bongos are actually there in all players (channel 11), but they are more quiet in case of Analog Kit than in case of Rock Kit.
The same is true for the 'stronger snare'.
So all in all, the other players play this song properly and TMIDI has a strange (and wrong) approach when playing multiple drum channels.

PS:
Maybe the idea behind TMIDI's behavior is that in case of Midi devices that cannot use more than 1 drum channel (only channel 10 as defined by GM) you can still hear at least drum sounds even in case of multi-drum channel XG files. Maybe this is true also for multi-drum channel GS files when played by TMIDI. I do not know since I have not tested this.

Now, I'm thinking about adding TMIDI's 'wrong' implementation as an optional feature to FSMP 😀
This way drum channel constrained devices like Sound Blaster HW SF2 synths could play multi-drum channel XG/GS Midi files somewhat better.

Hey, thank you for taking your time to investigate this. Now it all makes perfect sense, TMIDI's behaviour is erroneous one, not accounting for the fact that XG standard can initialise any channel as a drum channel.

BTW, i've also been using S-YXG50 as the output synth in all my listening cases, as it's the only way to playback XG MIDI properly, other than owning physical MU-xx synths which are unfortunately rare.

Trelokk wrote on 2024-10-06, 10:14:

... I updated BassMidi VSTi from v2.3 to v2.5 and now it seems I cannot save settings any more when using the soundfont. I am loading the sf2 as default soundfont, start adjusting the sliders and suddenly the setup window closes, with an error message saying "Cannot save plugin settings for BassMidiVsti!". When I reload, everything is back to default, no soundfont selected. The crash basically already happens after selecting the soundfont itself, I don't have to adjust any setting. The window will just close after a few seconds without doing anything else.

Since BassMidi VSTi has neither 2.3 nor 2.5 version I though you were talking about VST Midi Driver. And indeed I could successfully reproduce the problem.
There is a hotfix released because of this:
Re: VST Midi Driver Midi Mapper
BTW, you can still configure any plugins and save the settings even with version 2.5.0 when the driver is active as I have shown on my previous video. When the driver is active the saving of settings is not automatic, you have to press the 'Save Settings' button on the lower right side of the plugin's editor dialog.

Falcosoft wrote on 2024-09-28, 20:43:

1. Oh, yes. Midi 2.0 SMF2CLIP format has been defined since June 15 2023. 2. First here is the part from the loader that parses […]
Show full quote

Spesek wrote on 2024-09-28, 19:29:

1. I'm assuming that these are MIDI2 (and also according to README they are): https://github.com/jazz-soft/test-midi-files/tree/main/midi2
2. Thanks! 😁

1. Oh, yes. Midi 2.0 SMF2CLIP format has been defined since June 15 2023.
2. First here is the part from the loader that parses meta events of a track:

Copy code to clipboard

1          TempPort := 0;
2           ...             
3          case metaEvent of
4                  metaTrackName :
5                   begin
6                    if System.Pos('PartB', st) > 0 then TempPort := 1
7                    else if System.Pos('PartC', st) > 0 then TempPort := 2
8                    else if System.Pos('PartD', st) > 0 then TempPort := 3
9                    else if (Length(st) >= 2) and (st[1] in ['B', 'C', 'D']) then
10                    begin
11                      st2 := Copy(st, 2, 2);
12                      val(st2, sval, scode);
13                      if (st[1] = 'B') and (scode = 0) then
14                        TempPort := 1
15                      else if (st[1] = 'C') and (scode = 0) then
16                        TempPort := 2
17                      else if (st[1] = 'D') and (scode = 0) then
18                        TempPort := 3;
19                    end;
20                   end;
21                  metaDeviceName:
22                    if events^.sysexSize > 1 then
23                    begin
24                      pc := events^.data.sysex + 1;
25                      setlength(DeviceName, events^.sysexSize - 1);
26                      move(pc^, DeviceName[1], events^.sysexSize - 1);
27                    end;
28                  metaMIDIPort:
29                    begin
30                      if (events^.sysexSize > 1) then
31                       TempPort := Byte(events^.data.sysex[1]);
32                    end;

Then (after a track is fully loaded) there is an additional part that calculates Midi port from Midi device name (if it is present).

Copy code to clipboard

1//falco: port calculation from DeviceName (MetaEvent 0x9)
2      if (track.DeviceName <> '') and (track.TempPort = 0) then
3      begin
4        st := LowerCase(Trim(track.DeviceName));
5        i := DeviceNameList.IndexOf(st);
6        if i = -1 then
7          track.TempPort := DeviceNameList.Add(st)
8        else
9          track.TempPort := i;
10      end;
11    

Hi again Falco,

1st of all, thanks so much for this!

Secondly, I found a bug actually regarding the MIDI ports.

The attached file is a multi-port file, but FSMP6 fails to recognize it.
You can see in the event editor that track 15 uses port pref. 1, so effectively channel 17.
This is clearly noticeable because channel 1 is meant to be drums and channel 17 some other instrument,
but it replaces channel 1 with itself, resulting in the lack of drums. You can hear the correct sounds in spessasynth.

Thirdly: I have a question: what are the default values for all 127 controllers in FSMP6? For example 74 is set to 64 by default... Also, what happens internally (in BASS) if i play with CCs like data entry or RPNs using the knobs?

Falcosoft wrote on 2024-10-06, 18:05:

Since BassMidi VSTi has neither 2.3 nor 2.5 version I though you were talking about VST Midi Driver. And indeed I could successf […]
Show full quote

Since BassMidi VSTi has neither 2.3 nor 2.5 version I though you were talking about VST Midi Driver. And indeed I could successfully reproduce the problem.
There is a hotfix released because of this:
Re: VST Midi Driver Midi Mapper
[...]

You are right, of course. I confused the plugin and the driver. Thanks a lot for the fast fix! I also acquired very latest bass.dll and bassmidi.dll files from the un4seen beta section, just to be sure. I guess in the next BassMidi VSTi release, the option should be renamed to something like "Emulate SB hardware limits" (without the "Do not") since it's off by default in latest bassmidi.dll.

Trelokk wrote on 2024-10-06, 20:00:

Falcosoft wrote on 2024-10-06, 18:05:

Since BassMidi VSTi has neither 2.3 nor 2.5 version I though you were talking about VST Midi Driver. And indeed I could successf […]
Show full quote

Since BassMidi VSTi has neither 2.3 nor 2.5 version I though you were talking about VST Midi Driver. And indeed I could successfully reproduce the problem.
There is a hotfix released because of this:
Re: VST Midi Driver Midi Mapper
[...]

You are right, of course. I confused the plugin and the driver. Thanks a lot for the fast fix! I also acquired very latest bass.dll and bassmidi.dll files from the un4seen beta section, just to be sure. I guess in the next BassMidi VSTi release, the option should be renamed to something like "Emulate SB hardware limits" (without the "Do not") since it's off by default in latest bassmidi.dll.

Hi,
To tell you the truth I would like to preserve the SB emulation mode as default. I always liked Bassmidi better than e.g. Fluidsynth since it was more SB compatible. In later Bassmidi versions there is a tendency to give up this SB compatibility that I do not like much.

Spesek wrote on 2024-10-06, 19:43:

Hi again Falco, […]
Show full quote

Falcosoft wrote on 2024-09-28, 20:43:

1. Oh, yes. Midi 2.0 SMF2CLIP format has been defined since June 15 2023. 2. First here is the part from the loader that parses […]
Show full quote

Spesek wrote on 2024-09-28, 19:29:

1. I'm assuming that these are MIDI2 (and also according to README they are): https://github.com/jazz-soft/test-midi-files/tree/main/midi2
2. Thanks! 😁

1. Oh, yes. Midi 2.0 SMF2CLIP format has been defined since June 15 2023.
2. First here is the part from the loader that parses meta events of a track:

Copy code to clipboard

1          TempPort := 0;
2           ...             
3          case metaEvent of
4                  metaTrackName :
5                   begin
6                    if System.Pos('PartB', st) > 0 then TempPort := 1
7                    else if System.Pos('PartC', st) > 0 then TempPort := 2
8                    else if System.Pos('PartD', st) > 0 then TempPort := 3
9                    else if (Length(st) >= 2) and (st[1] in ['B', 'C', 'D']) then
10                    begin
11                      st2 := Copy(st, 2, 2);
12                      val(st2, sval, scode);
13                      if (st[1] = 'B') and (scode = 0) then
14                        TempPort := 1
15                      else if (st[1] = 'C') and (scode = 0) then
16                        TempPort := 2
17                      else if (st[1] = 'D') and (scode = 0) then
18                        TempPort := 3;
19                    end;
20                   end;
21                  metaDeviceName:
22                    if events^.sysexSize > 1 then
23                    begin
24                      pc := events^.data.sysex + 1;
25                      setlength(DeviceName, events^.sysexSize - 1);
26                      move(pc^, DeviceName[1], events^.sysexSize - 1);
27                    end;
28                  metaMIDIPort:
29                    begin
30                      if (events^.sysexSize > 1) then
31                       TempPort := Byte(events^.data.sysex[1]);
32                    end;

Then (after a track is fully loaded) there is an additional part that calculates Midi port from Midi device name (if it is present).

Copy code to clipboard

1//falco: port calculation from DeviceName (MetaEvent 0x9)
2      if (track.DeviceName <> '') and (track.TempPort = 0) then
3      begin
4        st := LowerCase(Trim(track.DeviceName));
5        i := DeviceNameList.IndexOf(st);
6        if i = -1 then
7          track.TempPort := DeviceNameList.Add(st)
8        else
9          track.TempPort := i;
10      end;
11    

Hi again Falco,

1st of all, thanks so much for this!

Secondly, I found a bug actually regarding the MIDI ports.

The attachment SEQ BGM04.zip is no longer available

The attached file is a multi-port file, but FSMP6 fails to recognize it.
You can see in the event editor that track 15 uses port pref. 1, so effectively channel 17.
This is clearly noticeable because channel 1 is meant to be drums and channel 17 some other instrument,
but it replaces channel 1 with itself, resulting in the lack of drums. You can hear the correct sounds in spessasynth.

Thirdly: I have a question: what are the default values for all 127 controllers in FSMP6? For example 74 is set to 64 by default... Also, what happens internally (in BASS) if i play with CCs like data entry or RPNs using the knobs?

Hi,
As I said said before there is also some logic in FSMP to detect 'false positive' multi-port Midi files. While 16+ track in a Midi file is not a marker for FSMP to identify multi-track Midi files but the other way around less than 17 track in Type 1 Midi file is a marker for FSMP to ignore port select messages since in this case there are enough channels in a single port domain for all possible instruments. It is true that you can craft such files that work this way but I could not find real multi port Midi files in the wild with such setup so far.

1if ((Filetype = 1) and (nTracks < 17)) then MaxMidiport := 0;

If I remove the above restriction then your file is working.

Falcosoft wrote on 2024-10-06, 20:50:

Hi, As I said said before there is also some logic in FSMP to detect 'false positive' multi-port Midi files. While 16+ track in […]
Show full quote

Spesek wrote on 2024-10-06, 19:43:

Hi again Falco, […]
Show full quote

Falcosoft wrote on 2024-09-28, 20:43:

1. Oh, yes. Midi 2.0 SMF2CLIP format has been defined since June 15 2023. 2. First here is the part from the loader that parses […]
Show full quote

1. Oh, yes. Midi 2.0 SMF2CLIP format has been defined since June 15 2023.
2. First here is the part from the loader that parses meta events of a track:

Copy code to clipboard

1          TempPort := 0;
2           ...             
3          case metaEvent of
4                  metaTrackName :
5                   begin
6                    if System.Pos('PartB', st) > 0 then TempPort := 1
7                    else if System.Pos('PartC', st) > 0 then TempPort := 2
8                    else if System.Pos('PartD', st) > 0 then TempPort := 3
9                    else if (Length(st) >= 2) and (st[1] in ['B', 'C', 'D']) then
10                    begin
11                      st2 := Copy(st, 2, 2);
12                      val(st2, sval, scode);
13                      if (st[1] = 'B') and (scode = 0) then
14                        TempPort := 1
15                      else if (st[1] = 'C') and (scode = 0) then
16                        TempPort := 2
17                      else if (st[1] = 'D') and (scode = 0) then
18                        TempPort := 3;
19                    end;
20                   end;
21                  metaDeviceName:
22                    if events^.sysexSize > 1 then
23                    begin
24                      pc := events^.data.sysex + 1;
25                      setlength(DeviceName, events^.sysexSize - 1);
26                      move(pc^, DeviceName[1], events^.sysexSize - 1);
27                    end;
28                  metaMIDIPort:
29                    begin
30                      if (events^.sysexSize > 1) then
31                       TempPort := Byte(events^.data.sysex[1]);
32                    end;

Then (after a track is fully loaded) there is an additional part that calculates Midi port from Midi device name (if it is present).

Copy code to clipboard

1//falco: port calculation from DeviceName (MetaEvent 0x9)
2      if (track.DeviceName <> '') and (track.TempPort = 0) then
3      begin
4        st := LowerCase(Trim(track.DeviceName));
5        i := DeviceNameList.IndexOf(st);
6        if i = -1 then
7          track.TempPort := DeviceNameList.Add(st)
8        else
9          track.TempPort := i;
10      end;
11    

Hi again Falco,

1st of all, thanks so much for this!

Secondly, I found a bug actually regarding the MIDI ports.

The attachment SEQ BGM04.zip is no longer available

The attached file is a multi-port file, but FSMP6 fails to recognize it.
You can see in the event editor that track 15 uses port pref. 1, so effectively channel 17.
This is clearly noticeable because channel 1 is meant to be drums and channel 17 some other instrument,
but it replaces channel 1 with itself, resulting in the lack of drums. You can hear the correct sounds in spessasynth.

Thirdly: I have a question: what are the default values for all 127 controllers in FSMP6? For example 74 is set to 64 by default... Also, what happens internally (in BASS) if i play with CCs like data entry or RPNs using the knobs?

Hi,
As I said said before there is also some logic in FSMP to detect 'false positive' multi-port Midi files. While 16+ track in a Midi file is not a marker for FSMP to identify multi-track Midi files but the other way around less than 17 track in Type 1 Midi file is a marker for FSMP to ignore port select messages since in this case there are enough channels in a single port domain for all possible instruments. It is true that you can craft such files that work this way but I could not find real multi port Midi files with such setup so far.

Copy code to clipboard

1if ((Filetype = 1) and (nTracks < 17)) then MaxMidiport := 0;

If I remove the above restriction then your file is working.

Here's where I found this MIDI file: https://github.com/FluidSynth/fluidsynth/issues/1352

I've just converted the MID + SF2 combo to RMI. The separate files don't work either.

Spesek wrote on 2024-10-06, 20:55:

Falcosoft wrote on 2024-10-06, 20:50:

Hi, As I said said before there is also some logic in FSMP to detect 'false positive' multi-port Midi files. While 16+ track in […]
Show full quote

Spesek wrote on 2024-10-06, 19:43:

Hi again Falco, […]
Show full quote

Hi again Falco,

1st of all, thanks so much for this!

Secondly, I found a bug actually regarding the MIDI ports.

The attachment SEQ BGM04.zip is no longer available

The attached file is a multi-port file, but FSMP6 fails to recognize it.
You can see in the event editor that track 15 uses port pref. 1, so effectively channel 17.
This is clearly noticeable because channel 1 is meant to be drums and channel 17 some other instrument,
but it replaces channel 1 with itself, resulting in the lack of drums. You can hear the correct sounds in spessasynth.

Thirdly: I have a question: what are the default values for all 127 controllers in FSMP6? For example 74 is set to 64 by default... Also, what happens internally (in BASS) if i play with CCs like data entry or RPNs using the knobs?

Hi,
As I said said before there is also some logic in FSMP to detect 'false positive' multi-port Midi files. While 16+ track in a Midi file is not a marker for FSMP to identify multi-track Midi files but the other way around less than 17 track in Type 1 Midi file is a marker for FSMP to ignore port select messages since in this case there are enough channels in a single port domain for all possible instruments. It is true that you can craft such files that work this way but I could not find real multi port Midi files with such setup so far.

Copy code to clipboard

1if ((Filetype = 1) and (nTracks < 17)) then MaxMidiport := 0;

If I remove the above restriction then your file is working.

Here's where I found this MIDI file: https://github.com/FluidSynth/fluidsynth/issues/1352

I've just converted the MID + SF2 combo to RMI. The separate files don't work either.

My problem is that I got reports about 'falsely' detected multi-port Midi files such as this:
Re: Falcosoft Soundfont Midi Player + Munt VSTi + BassMidi VSTi
In this moment I do not find the report that made me do this restriction so I'm inclined to remove it.
But the truth is in case of every heuristics there can be corner cases where the end result is not the desired one...

@Edit:
It was not hard to find a Midi file that became 'fake' multi-port because of this change:

You say about MIDI mapper in BassMIDI , remember I asked you about as set MIDI ports for WMP ? Then I asked about list numbers MIDI ports for WMP ) I then write what do this on VBS and offer you add port nuber in your WinMM Multiport VSTi )
So here I use CoolSoft VirtualMIDISynth for select and set WMP port , this is MIDI Mapper setter ) but have problem , sometimes that make troubles with WMP , for example:
If one software set Global MIDI Mapper port as 2 , and other program set WMP MIDI Mapper port as 4 , so after this will be summ errors and with set WMP MIDI Mapper port , it won't match with select.
If you not hard , please , create MIDI Mapper whitch will be set identical values for MIDI Port and if have difference , so clear both and rewrite select values
All software whitch I try before this problem not fixing nothing , so I hope for your help)
Certainly your WinMM MultiPort very simplified the situation, but still

Oh, I missed this:

Spesek wrote on 2024-10-06, 19:43:

Thirdly: I have a question: what are the default values for all 127 controllers in FSMP6? For example 74 is set to 64 by default... Also, what happens internally (in BASS) if i play with CCs like data entry or RPNs using the knobs?

1. These are the default controller values used by FSMP:
Re: Falcosoft Soundfont Midi Player
2. FSMP uses Bassmidi exactly like other MidiOut ports . Every Midi event is sent regardless it is supported or not by Bassmidi. FSMP does not use the separately defined events by Bassmidi but sends the events as 'raw' Midi data instead (BASS_MIDI_EVENTS_RAW).

Falcosoft wrote on 2024-10-06, 22:48:

Oh, I missed this: […]
Show full quote

Oh, I missed this:

Spesek wrote on 2024-10-06, 19:43:

Thirdly: I have a question: what are the default values for all 127 controllers in FSMP6? For example 74 is set to 64 by default... Also, what happens internally (in BASS) if i play with CCs like data entry or RPNs using the knobs?

1. These are the default controller values used by FSMP:
Re: Falcosoft Soundfont Midi Player
2. FSMP uses Bassmidi exactly like other MidiOut ports . Every Midi event is sent regardless it is supported or not by Bassmidi. FSMP do not use the separately defined events by Bassmidi but sends the events as 'raw' Midi data instead (BASS_MIDI_EVENTS_RAW).

Thanks! Can I copy over these defaults to Spessasynth?

Spesek wrote on 2024-10-06, 22:55:

Falcosoft wrote on 2024-10-06, 22:48:

Oh, I missed this: […]
Show full quote

Oh, I missed this:

Spesek wrote on 2024-10-06, 19:43:

Thirdly: I have a question: what are the default values for all 127 controllers in FSMP6? For example 74 is set to 64 by default... Also, what happens internally (in BASS) if i play with CCs like data entry or RPNs using the knobs?

1. These are the default controller values used by FSMP:
Re: Falcosoft Soundfont Midi Player
2. FSMP uses Bassmidi exactly like other MidiOut ports . Every Midi event is sent regardless it is supported or not by Bassmidi. FSMP do not use the separately defined events by Bassmidi but sends the events as 'raw' Midi data instead (BASS_MIDI_EVENTS_RAW).

Thanks! Can I copy over these defaults to Spessasynth?

Of course, they are not copyrighted 😀

Falcosoft wrote on 2024-10-06, 21:26:

My problem is that I got reports about 'falsely' detected multi-port Midi files such as this: Re: Falcosoft Soundfont Midi Playe […]
Show full quote

Spesek wrote on 2024-10-06, 20:55:

Falcosoft wrote on 2024-10-06, 20:50:

Hi, As I said said before there is also some logic in FSMP to detect 'false positive' multi-port Midi files. While 16+ track in […]
Show full quote

Hi,
As I said said before there is also some logic in FSMP to detect 'false positive' multi-port Midi files. While 16+ track in a Midi file is not a marker for FSMP to identify multi-track Midi files but the other way around less than 17 track in Type 1 Midi file is a marker for FSMP to ignore port select messages since in this case there are enough channels in a single port domain for all possible instruments. It is true that you can craft such files that work this way but I could not find real multi port Midi files with such setup so far.

Copy code to clipboard

1if ((Filetype = 1) and (nTracks < 17)) then MaxMidiport := 0;

If I remove the above restriction then your file is working.

Here's where I found this MIDI file: https://github.com/FluidSynth/fluidsynth/issues/1352

I've just converted the MID + SF2 combo to RMI. The separate files don't work either.

My problem is that I got reports about 'falsely' detected multi-port Midi files such as this:
Re: Falcosoft Soundfont Midi Player + Munt VSTi + BassMidi VSTi
In this moment I do not find the report that made me do this restriction so I'm inclined to remove it.
But the truth is in case of every heuristics there can be corner cases where the end result is not the desired one...

@Edit:
It was not hard to find a Midi file that became 'fake' multi-port because of this change:

I think it would be safer to keep the multiport handling logic as it was until now, or maybe add an advanced setting to alter this behaviour on demand.

Falcosoft wrote on 2024-10-05, 11:47:

Here is an experimental 32-bit test version (only the midiplayer.exe file is included so you need the full version and you have […]
Show full quote

Here is an experimental 32-bit test version (only the midiplayer.exe file is included so you need the full version and you have to overwrite the exe file with this).
There is a new comaptibility option in 'Main menu -> Compatibility Settings -> Play all GS/XG/GM2 drums on Ch.10'. If you enable this FSMP will play your file (and other multi-drum channel XG files) the same way as TMIDI. The setting also works for multi-drum channel GS and GM2 files.
Of course the default state is disabled.

The attachment MidiPlayer_65_x86_test.zip is no longer available

Thank you. I personally don't care about preserving TMIDI's (arguably erroneous) behaviour, but it might be useful for other people to have it as an optional feature. Although then, with that setting enabled, it might be a good idea to think about how to handle MIDIs that set ch10 to something that is a melodic istrument rather than drums - should these notes and channel settings be dropped entirely, or remapped to other channel if there's still free channels left? Again, this is not personally important to me, just some technical food for thought perhaps.

Lastly, i'd want to suggest a feature that i'd like to see implemented in FSMP. Namely, if any of the non-standard playback compatibility options (like the above TMIDI behaviour) is enabled, there should be an indicator lit up on the main display of the FSMP GUI. It could be just a single, global indicator that is active if any of these nonstandard playback settings are enabled (like an (!) icon or something similar, perhaps displaying a more detailed info in a pop-up window when clicked).

Attached is a mockup image illustrating my idea. Of course the final indicator style and placement might be different.

EDIT: Actually, on a second thought, i'm not really sure whether it's a good idea, since many of the options in "Compatibility Settings" menu aren't really ones that affect playback significantly or at all (Esc to Quit, Program Numbering, Use Only 1 CPU Core, etc). Scratch that.

Meowdori wrote on 2024-10-07, 17:07:

Thank you. I personally don't care about preserving TMIDI's (arguably erroneous) behaviour, but it might be useful for other peo […]
Show full quote

Falcosoft wrote on 2024-10-05, 11:47:

Here is an experimental 32-bit test version (only the midiplayer.exe file is included so you need the full version and you have […]
Show full quote

Here is an experimental 32-bit test version (only the midiplayer.exe file is included so you need the full version and you have to overwrite the exe file with this).
There is a new comaptibility option in 'Main menu -> Compatibility Settings -> Play all GS/XG/GM2 drums on Ch.10'. If you enable this FSMP will play your file (and other multi-drum channel XG files) the same way as TMIDI. The setting also works for multi-drum channel GS and GM2 files.
Of course the default state is disabled.

The attachment MidiPlayer_65_x86_test.zip is no longer available

Thank you. I personally don't care about preserving TMIDI's (arguably erroneous) behaviour, but it might be useful for other people to have it as an optional feature. Although then, with that setting enabled, it might be a good idea to think about how to handle MIDIs that set ch10 to something that is a melodic istrument rather than drums - should these notes and channel settings be dropped entirely, or remapped to other channel if there's still free channels left? Again, this is not personally important to me, just some technical food for thought perhaps.

Lastly, i'd want to suggest a feature that i'd like to see implemented in FSMP. Namely, if any of the non-standard playback compatibility options (like the above TMIDI behaviour) is enabled, there should be an indicator lit up on the main display of the FSMP GUI. It could be just a single, global indicator that is active if any of these nonstandard playback settings are enabled (like an (!) icon or something similar, perhaps displaying a more detailed info in a pop-up window when clicked).

Attached is a mockup image illustrating my idea. Of course the final indicator style and placement might be different.

EDIT: Actually, on a second thought, i'm not really sure whether it's a good idea, since many of the options in "Compatibility Settings" menu aren't really ones that affect playback significantly or at all (Esc to Quit, Program Numbering, Use Only 1 CPU Core, etc). Scratch that.

Hi,
1. Personally I have never met such Midi files. Do you have some examples?
While in theory such files are possible but in practice such files would play incorrectly even on some XG capable synths. Some XG implementations treat channel 10 always as drum channel even if Bank MSB 127 is not set. Try it on e.g. S-YXG50 and you will hear what I'm talking about.

2. I do not think it's necessary or rather I do not think it could be even helpful. In case of many compatibility settings it's hard to decide what state should be flagged as non-standard. These flags usually simply synth/hardware and not standard specific. Mostly some synths always prefer one state over the other.
So in case of some synths the user would always get the 'warning' sign and I do not think it could be helpful.

Probably a trivial question, but anyway:
When using the BassMIDI VSTi and switching from the GeneralUser soundfont to something like Masquerade 55, is it advisable to re-adjust Reverb and Chorus? I tweaked those settings according to the Github documentation. It's better to keep them at default otherwise?

Trelokk wrote on 2024-10-19, 07:22:

Probably a trivial question, but anyway:
When using the BassMIDI VSTi and switching from the GeneralUser soundfont to something like Masquerade 55, is it advisable to re-adjust Reverb and Chorus? I tweaked those settings according to the Github documentation. It's better to keep them at default otherwise?

I do not think there are objectively right or wrong Reverb and Chorus settings. It's all about personal aesthetic preferences. If the settings sound good for you with your other soundfont you can keep the settings.

Hi Falco,
I think I've found an issue with FSMP 6.5. The attached rmi (multi port) should use vibraphone lead on channel 1, but it uses piano in Midi player. When you look at the event viewer, you can see that the vibraphone program change gets called after the bright grand (vibraphone is the 8th event, while piano is 5th event).
You can compare the results with spessasynth, it uses vibraphone correctly.

Spesek wrote on 2024-11-22, 20:07:

Hi Falco,
I think I've found an issue with FSMP 6.5. The attached rmi (multi port) should use vibraphone lead on channel 1, but it uses piano in Midi player. When you look at the event viewer, you can see that the vibraphone program change gets called after the bright grand (vibraphone is the 8th event, while piano is 5th event).
You can compare the results with spessasynth, it uses vibraphone correctly.

Hi,
As I said before FSMP does not consider type 1 Midi files with less than 17 tracks to be valid multi port Midi files:

1if ((Filetype = 1) and (nTracks < 17)) then MaxMidiport := 0;

I do not think I would like to change this.
This way both the vibraphone and the piano program change events refer to the same port and the same channel and both have the exact same time/tick (0). Since the piano event is on a later track it is sent later. This is perfectly right behavior according to specification. The intended behavior most likely is that Vibraphone should be played on port 0 channel 1 and Piano on port 1 channel 1. If I remove the above restriction then the file is played this way.
But to tell you the truth these kind of files do not make any sense since instead of using 2 tracks that both use channel 1 on 2 different ports the 2nd track could use another channel on the same port (channels 6, 7, 9, 11 etc. are unused on port 0).

Thanks for the response, Falco.
I forgot about that limit, sorry!
Most of the multi port files I have are like this, a mess of mixed up tracks, unfortunately.
They come from a website called musescore, which is quite popular AFAIK. But if you don't want remove the 17 track restriction, then that's fine.
The one i sent indeed uses vibra on channel 0 and piano on p1 ch01.

PS: When will you release 6.5 with DBNK support available on your website?

PS/2: Does FSMP6 have an option to render the MIDI to audio via BASS?