drumkit bug

Please let our ADS show!

This sites offers only FREE software and it's supported by a few advertisement boxes (no intrusive popups).
Please:

  • disable your AdBlocker by adding CoolSoft website to whitelist
  • give the proper cookie consent
  • enable JavaScript for this website

This seconds wait is to let you update your browser configuration...

Ok, I've done the required changes... now show me your content!
!!! Please enable JavaScript !!!

Pagine

Posts: 30
Joined: 19 Apr 2017 - 08:14
Re: drumkit bug

There is a minimum XG soundfont (3.5MB) made by Yamaha (and remapped by Zandro) at the following web address.

https://skydrive.live.com/embedicon.aspx/%E9%9F%B3%E6%A5%BD%E9%96%A2%E9%...

Drumsets are in both 127.(XG) and 128.(GS) banks.

I added this website address (for XG soundfont) , because it's relevant to the topic and can be used for testing.

Posts: 129
Joined: 25 Set 2013 - 16:38
Re: drumkit bug
ex-driver wrote:

Only with sysex reset on a player means that the config is only able to play it in a player not for dosgames. That means MT-32 sf2 must split to another own sf2 file  programmed to preset 000:""" that works native with this online sf2 so u must not reset it.

Ah, I forgot one important thing. SysEx mode switch to MT-32 mode is not only required for using Bank 127, but also for setting other different default parameters such as Pitch Bend range. By default MT-32 uses 12 semitones but by default GM/GS devices use 2 semitones. So if you use your Bank 0 MT-32 soundfont without sending the proper SysEx initialization, MT-32 midi songs/games will have a high chance to sound bad when they use Pitch bend controller messages (e.g. in guitar solos).

Ziya Mete Demircan wrote:
There is a minimum XG soundfont (3.5MB) made by Yamaha (and remapped by Zandro) at the following web address.

Sorry to say, but this XG soundfont is not made by Yamaha. Actually Yamaha never made any SF2 soundfonts and never made any software or hardware that supported SF2 soundfonts. One one hand SF2 soundfonts was a concurrent technlogy for Yamaha (supported by EMU/Creative Labs), on the other hand (as I have said above) the SF2 format is rather GS like and is not capable to store the 2 dimensional banks required by XG (Bank MSB+LSB addressing). In your linked soundfont only the samples are from Yamaha, supposedly from DB50XG.
This soundfont is a heroic effort by someone to fit the 2 dimensional XG Banks into the 1 bank dimension of SF2 format and make the soundfont 'XG compatible' but unfortunately this is only partly possible...

Posts: 30
Joined: 19 Apr 2017 - 08:14
Re: drumkit bug

I thought it was an official soundfont. (sorry for this)
I even tried to simulate the voices there for my own soundfont :)
Also, the presence of drums on the 127th bank works on XMPlay. (If you have marked the required feature -> "Use Bank 127 drums in XG Mode when Available")
I used this feature on my own SoundFont. And the XG-enabled midi's play nicely with this setup. Because of the XG drum-maps is (a little bit) different than GS.

Posts: 129
Joined: 25 Set 2013 - 16:38
Re: drumkit bug

@Claudio:

I have checked other implementations and only XMPlay seems to handle all possibilities correctly. Kode 54's implementation (tested with foobar + foomidi plugin) is more wrong than VMS/Bassmidi's default since it always handles bank 127 as drum bank and so it does not work even with really official GS soundfonts like Creative's (e.g. CT4MGM.SF2) that use bank 127 as an MT-32 bank. XMPlay must use some additional heuristics since it works properly even with GS soundfonts when 'use 127 bank drums in XG mode' is checked.

I have an idea about solving this problem without putting the burden of choices to the users. If we implement something like this together at least VMS and FSMP would be compatible with each other in this respect.

Arguably not many users know the internal structure of the soundfonts they use + the concept of banks + XG system pecularities, and these are necessary to make the right choice.  So instead of an option a heuristic like this could be used:

If lowercase(bank 127 : preset 0) contains string "standard" and lowercase(bank 127 : preset 8) contains string "room" then use the BASS_MIDI_FONT_XGDRUMS flag. I have checked some XG soundfonts and they all fullfill this requirement. It makes sense since no MT-32 compatible bank in GS soundfonts use even similar preset names. So the burden would be on soundfont makers instead of users. Ex-driver should follow this convention and rename his Bank 127 preset 0 like 'Standard kit' or 'Standard XG' etc. and also should implement room preset similar way.

What do you think?

I have uploaded a test version of FSMP whose internal Bassmidi synth uses this convention:

http://falcosoft.hu/midiplayer_54_test.zip

Posts: 61
Joined: 20 Maggio 2018 - 02:30
Re: drumkit bug

Maybe we should ask Ian Luck for this. What he did. ;)

I have checked other implementations and only XMPlay seems to handle all possibilities correctly. Kode 54's implementation (tested with foobar + foomidi plugin) is more wrong than VMS/Bassmidi's default since it always handles bank 127 as drum bank and so it does not work even with really official GS soundfonts like Creative's (e.g. CT4MGM.SF2) that use bank 127 as an MT-32 bank. XMPlay must use some additional heuristics since it works properly even with GS soundfonts when 'use 127 bank drums in XG mode' is checked.

[email protected] >>>his e-mail

I'm working on my Soundfont to set the missing bank numbers like 127:000 and 127:008.

Ex-driver should follow this convention and rename his Bank 127 preset 0 like 'Standard kit' or 'Standard XG' etc. and also should implement room preset similar way.

BTW Thx for your effort Falcon ;)

Posts: 1972
Joined: 25 Mar 2012 - 01:19
Re: drumkit bug

Sorry all for the late reply, still working hard on next 2.5.0 version...

falcosoft wrote:
Arguably not many users know the internal structure of the soundfonts they use + the concept of banks + XG system pecularities, and these are necassary to make the right choice.
I put myself in this group of users too ;)

falcosoft wrote:
So instead of an option a heuristic like this could be used:
Heuristic auto-selection should be great but should anyway be documented and well-known.
The most of the users will never need to know how it works, I agree, but I wonder how hard could it be to debug a misworking soundfont that doesn't respect this new rule.

Again, the most important thing to understand for me is if this setting is needed only in very specific conditions (I think YES).
If yes, then I think it's better to

  • create a new per-soundfont setting with a disabled default value (as it's now)
  • being a per-soundfont setting, add a checkbox to soundfont edit dialog (which is usually accessed only by advanced users) to enable/disable it for that soundfont

This way when an user who configures a particular soundfont that doesn't work as expected, looking at its configuration dialog could try to check/uncheck that new option "Enable drum bank remapping" (or something more technical) even if it doesn't know what's he doing.

No one wants to avoid adding "obscure" options to software more than me, but I'd like to think twice about an "heuristic" algorithm that I can't fully understand (I'm in the group of users that don't know soundfont internals as you know ;))

Posts: 1972
Joined: 25 Mar 2012 - 01:19
Re: drumkit bug

First issue I've seen when trying to implement the "heuristic" algorithm:

falcosoft wrote:
If lowercase(bank 127 : preset 0) contains string "standard" and lowercase(bank 127 : preset 8) contains string "room" then use the BASS_MIDI_FONT_XGDRUMS flag.

To do these checks on the given SF2, BASS needs an handle on it thus it was already initialized.
After the check, if positive, we need to uninitialize then reinitialize it with the additional flag (unless there's the possibility to add it after initialization, but havent found a way to do it).

I thought about another solution that combines both, heuristic + user option:

  • add a configurable SF option, disabled by default
  • when user adds a new SF2 to configuration, VMS will parse the given file and enables/disables the new configuration option based on the "heuristic" algorithm then set/unset the new option
  • user is still able to chenge the automatic choice made by VMS if needed
  • VMS does not need to retest the SF2 file anymore

Is it good enough?

Again, how should the new option be called?
I thought something like this (took from BASS documentation): Use bank 127 for XG drum kits, then fallback to 128

Posts: 61
Joined: 20 Maggio 2018 - 02:30
Re: drumkit bug

At first. Thx for hard working on it. The option sounds good maybe with: (  for pure XG Mode support). =)

Posts: 129
Joined: 25 Set 2013 - 16:38
Re: drumkit bug

Yes, I think the heuristic + user option is a good solution.

My recommendation for the option's label is: Use bank 127 for drum kits in XG mode.

It's a little bit less technical and expresses the essence of the option more clearly.

Posts: 1972
Joined: 25 Mar 2012 - 01:19
Re: drumkit bug

I've added the new feature to the just released 2.5.0-RC1.
https://coolsoft.altervista.org/en/forum/thread/645

2.5.0 is now feature freeze, feel free to test it and report any bug in that thread before the final release...

Pagine