I known what SFark not supported in BASSMIDI , I gived link to you can adaptate this for BASSMIDI because project opensource

Roland User wrote on 2024-05-18, 19:47:

I known what SFark not supported in BASSMIDI , I gived link to you can adaptate this for BASSMIDI because project opensource

Sorry , but I will not do it.
BTW, BassMidi VSTi is not GPL licensed/open source so I could not use the linked library even if I wanted.

Thank you ) I not known this before)
Be the way , your BASSMIDI VSTi not correctly work with sf2pack if do compress in OPUS )

despite what BASSMIDI from http://jasonwilliams400com.startlogic.com/sno … ASSMIDI_Driver/ support compress to OPUS , but your version can not detect instruments in so SF2Pack file if compress to OPUS

Roland User wrote on 2024-05-18, 21:04:

Thank you ) I not known this before)
Be the way , your BASSMIDI VSTi not correctly work with sf2pack if do compress in OPUS )

despite what BASSMIDI from http://jasonwilliams400com.startlogic.com/sno … ASSMIDI_Driver/ support compress to OPUS , but your version can not detect instruments in so SF2Pack file if compress to OPUS

Besides Opus, dsd and alac etc. are not supported either but bass has extensions for them. The reason is simple:I have never encountered SF2/Sfz files that were compressed by them so I could not even test them. Wavpack and flac are supported and tested since they are actually used (mostly by existing Sfz files). I think the main reason is that they are loseless codecs unlike Opus.

Yes ) here I agre )
But MP3 and Vorbis is lossy codecs , hovever this variants work normaly unlike Opus ) so need fix this if not hard and there is a desire )
Besides Opus better what MP3 and Opus on quality very close to Vorbis and sometimes Opus better what Vorbis )

Falcosoft wrote on 2024-05-18, 20:11:

Sorry , but I will not do it.
BTW, BassMidi VSTi is not GPL licensed/open source so I could not use the linked library even if I wanted.

Are you sure you can not do this ?
After all I find this :
https://github.com/kode54/BASSMIDI-Driver
https://github.com/KeppySoftware/OmniMIDI
This also not a GPL license ? Or this liecense allows you add support sfarck to SF synth ?

1. Mp3 and Vorbis work without any extensions in Bassmidi. Ask Ian from Un4seen why.
I have zero line of codes to support them. In fact I could not even"disable" them even if I wanted.

2. Yes, I'm absolutely sure. Do you even know how GPL works?
You cannot use GPL licensed code in closed source projects. It is just that simple.
BTW, the projects you linked have nothing to do with SfArk support/GPL. I do not even understand why you think they are relevant.
SFpacker in those projects does not use GPL code and does not support SFark either.
And let's stop here. it's tiresome again..

1) I thinked what this projects moved from https://www.un4seen.com/ to github and become with open source whitch can use as wanted , I true not known about diffirences licensies )
2) Good )

https://jacobspiano.com/wp-content/uploads/20 … a-MIDI-Demo.mid

This files, free demo, and his other files, report incorrect durations. Why is this?

Karmeck wrote on 2024-05-20, 12:32:

https://jacobspiano.com/wp-content/uploads/20 … a-MIDI-Demo.mid

This files, free demo, and his other files, report incorrect durations. Why is this?

Because according to SMF/Midi specification this file is 'broken' in the sense that it really is 2:16:32.94 long (namely it has the End of Track Midi event at this position):

But Midi Player has a compatibility setting to cure such problematic Midi files.
'Main menu -> Compatibility Settings -> Ignore End of Track for Song Length' option has to be enabled.

Falcosoft
Since spech about MIDI files , I to ask about errors )
If I modify any MIDI file and integrate in file any insert effects use XG Works , and after open this file in Cakewalk - I can not play this file , why ?

Roland User wrote on 2024-05-20, 23:06:

Falcosoft
Since spech about MIDI files , I to ask about errors )
If I modify any MIDI file and integrate in file any insert effects use XG Works , and after open this file in Cakewalk - I can not play this file , why ?

Because this Midi file is simply insane. It has 10000+ SysEx messages at 1st track and all of these SysEx messages start at position 0 at once. This file most likely would freeze many HW Synths.

Where do you people even find these weird MIDI files 😁

This MIDI file I recive easy add delay to GM compositon in XG Works )

I thought I'd might let Falcosoft know that the Midi Player has a really hard time looping XMI's for some reason.

The XMI's from Blackthorne and Jagged Alliance loop at wildly improper positions compared to what I hear actually ingame and with XMIPLAY.

Since EMIDI was brought up earlier, I noticed the loops seem to work correctly in EMIDI files, just some XMI's I throw at this thing have completely incorrect looping positions.

DracoNihil wrote on 2024-05-22, 14:44:

I thought I'd might let Falcosoft know that the Midi Player has a really hard time looping XMI's for some reason.

The XMI's from Blackthorne and Jagged Alliance loop at wildly improper positions compared to what I hear actually ingame and with XMIPLAY.

Since EMIDI was brought up earlier, I noticed the loops seem to work correctly in EMIDI files, just some XMI's I throw at this thing have completely incorrect looping positions.

Hi,
It would be helpful if you could attach the affected XMI files.
Also some more details about the difference between what you experience and what you expect would be helpful.
Notice that I have not got these games. I could only download the Blackthorne rips from here:
https://www.vgmpf.com/Wiki/index.php?ti ... orne_(DOS)

Falcosoft wrote on 2024-05-22, 15:14:

Hi, It would be helpful if you could attach the affected XMI files. Also some more details about the difference between what yo […]
Show full quote

DracoNihil wrote on 2024-05-22, 14:44:

I thought I'd might let Falcosoft know that the Midi Player has a really hard time looping XMI's for some reason.

The XMI's from Blackthorne and Jagged Alliance loop at wildly improper positions compared to what I hear actually ingame and with XMIPLAY.

Since EMIDI was brought up earlier, I noticed the loops seem to work correctly in EMIDI files, just some XMI's I throw at this thing have completely incorrect looping positions.

Hi,
It would be helpful if you could attach the affected XMI files.
Also some more details about the difference between what you experience and what you expect would be helpful.
Notice that I have not got these games. I could only download the Blackthorne rips from here:
https://www.vgmpf.com/Wiki/index.php?ti ... orne_(DOS)

I should have linked that, sorry. The Jagged Alliance XMI's are also available from there: https://www.vgmpf.com/Wiki/index.php?ti ... ance_(DOS)

I don't know how to describe the improper loop in Blackthorne's first ingame track, it's like the program thinks the loop start is several segments ahead of where it's actually at. Most of the Jagged Alliance XMI's either loop straight back to the beginning of file, or several steps ahead of where it's supposed to actually loop as well.

The looping in Blackthorne works correctly in "Hoot... Sound Hardware Emulator" that was originally where I even got the Blackthrone XMI's from. The loop points also work correctly in whatever MIDI player that was used in "Droidsound-E" on my old smartphone.

DracoNihil wrote on 2024-05-22, 16:22:

I should have linked that, sorry. The Jagged Alliance XMI's are also available from there: https://www.vgmpf.com/Wiki/index.php? […]
Show full quote

Falcosoft wrote on 2024-05-22, 15:14:

Hi, It would be helpful if you could attach the affected XMI files. Also some more details about the difference between what yo […]
Show full quote

DracoNihil wrote on 2024-05-22, 14:44:

I thought I'd might let Falcosoft know that the Midi Player has a really hard time looping XMI's for some reason.

The XMI's from Blackthorne and Jagged Alliance loop at wildly improper positions compared to what I hear actually ingame and with XMIPLAY.

Since EMIDI was brought up earlier, I noticed the loops seem to work correctly in EMIDI files, just some XMI's I throw at this thing have completely incorrect looping positions.

Hi,
It would be helpful if you could attach the affected XMI files.
Also some more details about the difference between what you experience and what you expect would be helpful.
Notice that I have not got these games. I could only download the Blackthorne rips from here:
https://www.vgmpf.com/Wiki/index.php?ti ... orne_(DOS)

I should have linked that, sorry. The Jagged Alliance XMI's are also available from there: https://www.vgmpf.com/Wiki/index.php?ti ... ance_(DOS)

I don't know how to describe the improper loop in Blackthorne's first ingame track, it's like the program thinks the loop start is several segments ahead of where it's actually at. Most of the Jagged Alliance XMI's either loop straight back to the beginning of file, or several steps ahead of where it's supposed to actually loop as well.

The looping in Blackthorne works correctly in "Hoot... Sound Hardware Emulator" that was originally where I even got the Blackthrone XMI's from. The loop points also work correctly in whatever MIDI player that was used in "Droidsound-E" on my old smartphone.

I think I have found the problem and it's not easy to solve it fully.
The problem is that FSMP also supports many other types of Loop markers. One of them is RPG Maker style when only one controller message marks the Loop point: CC#111 with 2nd byte zero. In XMI specification Loop point markers are different (CC#116 and CC#117) but in XMI spec you can also find that CC#111 also means 'something' but no one knows exactly what it is. But it seems it's not important in the context of simple playback:
https://moddingwiki.shikadi.net/wiki/XMI_Format
So far I have only met XMI files that have CC#111 with non-zero 2nd byte. But your problematic files do contain CC#111 with zero 2nd byte. It's exatly the same as RPG Maker style loop markers.
The only thing I could do is to disable these kind of loop markers in case of XMI files. The problem is that converted XMI to MID files also contain these types of markers (like 03 - Level 1-4.xmi.mid) and there is nothing you can do anymore in this context to determine what is valid loop marker and what is not.
So I could only correct the error in case of XMI files but not in case of MID files converted from XMI files...
In case of these converted MID files you can remove CC#111 with 2nd byte zero events without any consequences to cure the problem since it is sure that they mean nothing in MID files.
Here is a test version for you to try:
https://falcosoft.hu/midiplayer_64_test.zip

Falcosoft
I met XMI format only one game Extreme Assault ) this the only one game wich I have with this format )
So you sayd what have problem with specifc CC in file , I can offer do support read two version XMI for example XMI read as standard XMI and XMIE read as XMI with this problem
I think what so will be better , because will be select as read read , and if need read problem file , easy rename extension and read with fix ) and FSMP will be detect as read on extension

Roland User wrote on 2024-05-22, 22:21:

Falcosoft I met XMI format only one game Extreme Assault ) this the only one game wich I have with this format ) So you sayd wha […]
Show full quote

Falcosoft
I met XMI format only one game Extreme Assault ) this the only one game wich I have with this format )
So you sayd what have problem with specifc CC in file , I can offer do support read two version XMI for example XMI read as standard XMI and XMIE read as XMI with this problem
I think what so will be better , because will be select as read read , and if need read problem file , easy rename extension and read with fix ) and FSMP will be detect as read on extension

The problem is with standard MIDI files (.mid) that are converted from XMI files, not with XMI files.