hydrogen-music / hydrogen

The advanced drum machine for Linux, macOS, and Windows
http://www.hydrogen-music.org
GNU General Public License v2.0
1.04k stars 172 forks source link

add option to tag drumkit as GMcompliant #38

Closed thijz closed 12 months ago

thijz commented 12 years ago

we need to add a 'tags' field to the drumkit xml to be able to distinguish between GMcompliant and non-compliant kits

example by Sebastian:

GM compliant

this way H2 can add some sort of graphical indication for that drumkit this makes it easier for the users

milasudril commented 10 years ago

It would be better to have it on note level since it may happen that a drumkit is only partially compliant. For example, I have a TR-909 kit, which can never be fully GM compliant unless you invent new sounds. If I map all samples correctly, the kit must have unused slots, and therefore it is not fully compliant.

mauser commented 8 years ago

Newer ticket (marked as duplicate) with concept art: #391

trebmuh commented 8 years ago

Here is the mockup referred to by mauser above:

bf312d58-5e3e-11e6-9a9b-936dfafa1e88

theGreatWhiteShark commented 12 months ago

Hmm. I think adding such a tag is not feasible.

The drumkit.xml files are written by the persons creating the drumkits and not by us. Therefore we can not guarantee for this tag to actually correspond to GM compliance. Second, even in case we update the definitions of the kits we host at SourceForge only users binning their local kits and reinstalling all of them will benefit.

milasudril commented 11 months ago

@theGreatWhiteShark Obviously, you cannot trust any instrument (drum-kit or other) to be GM compliant. And what is the sound of a kick.drum or piano anyways, not to mention the more abstract sounds from the GM set ie Sci-Fi or Halo Pad.

Maybe MMA has some kind of reference synthesizer, and to claim that you are GM compliant, a jury must compare your synthesizer with the reference synthesizer to certify it.

If the user of a drum kit thinks it is not GM compliant and it claims to be, that is a bug in the drum kit. So yes, I think it could be a good idea to support this tag. Especially if you want to filter out drum-kits that are not GM compliant. I agree that it must be per note, and if some notes do not match, it should be shown as partial, and there should be an option to find out which do not match.

theGreatWhiteShark commented 11 months ago

Hey @milasudril ,

Apart from the practical implications: what would be the benefit of having such a tag? Especially, if it is applied on instrument and not drumkit basis?

This might have been more relevant back in the days the issue was created and the discussions did take place. But today's kits are usually quite huge in size. And what do I make out of the information that one of the kit's snares and one of the kit's bass drum is complying with the GM standard while the other snares and bass drums do not?

elpescado commented 11 months ago

I think a general tagging mechanism for drumkits is - in principle - a useful idea. Maybe not an urgent one, as there isn't that many drum kits out there. Also, I do not see any issues with the fact that the sole "certification" lies in the hands of the author and we have no means to verify it automatically, nor with the fact that "legacy" drum kits won't have that information.

On the other hand, I see some issues with tagging kits as a "GM compliant", most of which boil down to the question of what constitutes a "compliance" with GM.

First, General Midi standard defines no less that 47 drum sounds in "General MIDI Level 1 Percussion Key Map". Currently, I know of no kits that include full set of 47 instruments.

Evaluating GM compliance for individual instruments is equivalent to asking whether instrument has a MIDI note assigned according to spec. There's one - rather minor - issue with that, GM standard defines more than one note for a given instrument, i.e. for crash cymbal there's 49 ("Crash Cymbal 1") and 57 ("Crash Cymbal 2") - those make sense in the context of whole drum kit rather than individual instrument. The same for ride cymbal. But other than that it's pretty straightforward, although I'd argue that it adds relatively little information.

Then there's the question how to propagate that information to drum kit level to assess "partial compliance". We could compute ratio of compliant instruments, eg 3/47, but would that be actually beneficial? Consider:

All those kits would have the same partial compliance ratio, but they are not interchangeable at all.

Last, there's a question of "extra" sounds. General MIDI defines open and closed hi-hat, but it's common for kits to include 1/4, 2/4 and 3/4 open hi-hat as well. How those superfluous samples would effect GM compliance?

elpescado commented 11 months ago

BTW. maybe it'd be better, instead of focusing on GM spec, to evaluate drum kits in context of loaded song? For example, if a song uses instruments that map to MIDI notes 36, 38 and 42, then drumkits that provide such instruments get marked somehow. Of course, we'd need then "MIDI note-aware drum kit loader"...

theGreatWhiteShark commented 11 months ago

I think a general tagging mechanism for drumkits is - in principle - a useful idea. Maybe not an urgent one

That's actually the very thing I intend to implement for the upcoming 1.3.0 version of Hydrogen. The tagging itself is already done in #1850 but the core/gui parts for using it to switch/load drumkit and patterns is still in the making. That's why I'm very glad for all your feedback!

A more detailed description of what I have in mind can be found in #1691 but basic concept is as follows:

For each instrument within a kit one or more arbitrary tags can be assigned. There are stored in .h2map files that are loaded with the following precedence.

  1. <USR_DATA_DIR>/drumkit_maps/kit.h2map
  2. <INSTALLED_DRUMIT_DIR>/drumkit.h2map
  3. <SYS_DATA_DIR>/drumkit_maps/kit.h2map

Using 3. we provide tags for all kits found on SourceForge, using 2. the person creating the kit can define it herself, and using 1. the user can override any of these.

Switching between kits and loading of pattern can than be done on the basis of tag matching. In your example the user could define once that "kick", "acoustic bass drum", and "cabana" have the same tag, e.g. called "Kick", and switching between those kits will automatically map the notes between the corresponding instruments. Regardless of their order.

That's the plan for 1.3.0.

Going one step further we could have a dedicated tab in the Preferences aggregating all tags found in all installed kits and associate them with MIDI notes. There we could allow the user to base the MIDI output note mapping not on the values specified for each instrument in the drumkit but assigned to the tag herself. Then we could more or less seamlessly switch between kits without altering the MIDI settings. Default values we would provide ourselved based on GeneralMIDI. But that's massive work on UX to avoid all the confusion already present in the mapping of incoming MIDI notes.

Do you think this is the right way to proceed? And would it make such GM compliance tag redundant?

theGreatWhiteShark commented 11 months ago

BTW. maybe it'd be better, instead of focusing on GM spec, to evaluate drum kits in context of loaded song? For example, if a song uses instruments that map to MIDI notes 36, 38 and 42, then drumkits that provide such instruments get marked somehow. Of course, we'd need then "MIDI note-aware drum kit loader"...

Starting with 1.3.0 I want to put a proper drumkit into a song (see #1849) and properly introduce the notion of a current kit. All this stripping of metadata and putting just the instruments into a .h2song file caused a bunch of bugs. And still does. Therefore, regardless whether it involves a song or not, it will always be a mapping between drumkits.