Drumkit-independent patterns proposal

[theGreatWhiteShark]

Goal

We want to allow for a smooth changing between drumkits and for drumkit-independent patterns. It should be possible to load another drumkit on the current song and use it without being required to reprogram any pattern. Making patterns independent of a specific drumkit would increase their reusability a lot and would also allow for large web-based pattern collections.

I would implement this feature by mapping each instrument (of a drumkit, pattern, or song) to a general identifier (GID). When loading a pattern/switching a drumkit all notes are assigned to a new instrument holding the same GID as the previous one.

Storage

I would store those maps in the SoundLibrary next to the associated drumkit using std::pair<Drumkit*, std::multimap<QString(GID),int(instrument number)>>. It will be automatically loaded along side the drumkit from (a) the drumkit folder or (b) .hydrogen/data/mapping/DRUMKIT_NAME.h2map or initialized empty + warning if no such file could be found. (a) is treated as read-only and has lower precedence. (b) contains all mappings stored using the GUI or shipped by us.

The associated .h2map files are saved as XML and consist of a list of GID-instrument number pairs. (Not quite sure yet which will be the node and which its value). In future versions of Hydrogen the exported .h2drumkit bundles will also contain a .h2map but I won't modify the kits stored on SourceForge. Instead, I'll create mapping files for all of those kits myself which will be installed in /usr/share/hydrogen/data/mapping during upgrade. This way users are not required to discard and refill their local drumkit folder. The drumkit definition file won't be touched.

The .h2pattern definition, on the other hand, I intend to modify by adding an additional field for the GID for each note. For backward compatibility drumkit name and instrument number will still be written out and those two will be used in combination with the .h2map file of the associated kit when loading older patterns. But pattern definition already changed recently and the resulting one should still be compatible with older versions.

Within the .h2song there will be a mapping section too for the currently loaded drumkit.

GIDs

The particular strings we use as general identifiers (GID) for instruments are not formally defined in this design. As a recommendation and when writing all the mapping files I would use English names of General MIDI [1] and append number starting at 1 in case of multiple occurrences, like High Tom 1. Maybe it would be a good idea to maintain a wiki page listing all GIDs we use in our default mappings as Acoustic Snare and Electric Snare of the GM Standard should probably be merged into one.

Not defining a limited set makes it easy to support future kits, allows for easy customization, but probably will also result in some mismatches.

Hydrogen will collect all GIDs read from all mappings into a set and offers them as possible choices in the GUI. However, the user will also be able to set them to arbitrary strings.

UX

There will be two new windows:

1. A window accessible via Menu > Drumkits / the SoundLibrary to edit the mapping of the current kit (stored in the song) / of a drumkit found in the .hydrogen/data/drumkits/ folder.
2. A window allowing the user to resolve non-trivial mapping mismatches

Switching kits or loading patterns

The mapping itself is done by taking all GIDs of the instruments of the current kit / new pattern containing notes and searching for an instrument of the same GID in the target drumkit. If exactly one was found and exactly one instrument of the current kit holds this GID, the mapping is considered trivial and is done automatically.

If there is either no instrument with matching GID in the target kit or multiple instruments with the same GID in the current kit / pattern and/or target kit, the user has two options:

1. Using the new window the user can manually map each instrument containing notes to one or more instruments of the target kit. It will also allow for merging several instruments into one. In addition, an instrument can also be mapped to an empty instrument.
2. All instruments with non-trivial mapping will automatically be mapped to empty instruments.

Mapping to empty instruments will add an empty instrument at the bottom of the song's instrument list holding both the original instrument's notes and GID. When e.g. switching from a kit with 3 toms to a kit with 2 toms and back, one tom instrument will be muted in between but is again usable when switching back. This will become handy when e.g. cycling through all kits using a PC MIDI event.

Drumkits

• New instruments will be initialized with no GID
• Instruments without GIDs are highlighted in the pattern editor using an icon similar to the 'missing samples' one
• Duplicating (save as) a drumkit will duplicate its mapping as well
• Deleting a drumkit will also delete its mapping
• When importing a .h2drumkit bundle and a mapping file holding the same drumkit name is already present in .hydrogen/data/mapping the user is prompted whether to overwrite the existing mapping (as it would have higher precedence than the bundled one)
• Drag-dropping instruments from the SoundLibrary into the current song does import its GID as well
• The order of the instruments to be shown in the pattern editor can be set in the Preferences. Either classically by ascending instrument number or manually by a custom order of GIDs and a fallback to ascending instrument number for all instruments not matching any of the set GIDs.
• JACK per instrument output ports will be named according to the GID with a fallback to the instrument's name. This way the ports can stay intact when switching drumkits.

Patterns

• Saved or exported patterns do always get the GIDs of the song's current kit
• Saved songs are either stored in .hydrogen/data/pattern directly or in a subfolder matching its category in case this property was set. Previously, patterns were put in folders named according to their associated drumkits which will be obsolete.
• Patterns do have an info/description property. This will be used as tooltip in the pattern list of both song editor and sound library to ease selection.

Anything I missed or general remarks?

[1] https://en.wikipedia.org/wiki/General_MIDI#Percussion

[trebmuh]

@theGreatWhiteShark #38 is related

[theGreatWhiteShark]

Hmm... I have to think about it a little longer but in the same manner as the order of the instruments in the pattern editor can be set in the preferences one could also allow to overwrite the instrument's MIDI note settings using the GIDs.

This already feels like feature creep as the user could also edit those things in the drumkit.xml of the particular kits directly.

[elpescado]

Out of curiosity: why not use MIDI note property to do remapping? Granted, those are not set up properly in many (most?) drum kits, but the same holds for any new property.

[theGreatWhiteShark]

Granted, those are not set up properly in many (most?) drum kits, but the same holds for any new property.

Yes, this is one of the main reasons. I want some mechanism using which we can avoid patching all the kits hosted on SourceForge and without requiring the users to discard all downloaded kits (as a refresh is not supported).

The other big issue with using MIDI note property is that it is specified as a number. Imagine the user wants to map kit A on kit B with both of them containing non-GM conformant instruments. If we rely on numbers, all we can present in the GUI is that we failed to map instrument 90, 110, 203 for kit A as well as 100 and 101 for kit B. If kit creators can specify strings, we would be able to display instrument "floor tom 2", "rusty cowbell", "snare 2" for kit A and "floor tom 16x18" and "snare Sonor" which out of the box would be a lot more easy to map. Apart from this using numbers outside of the GM standard would likely cause false mappings unless we formally define a larger set.

[cme]

I've been wondering (in the process of #1699) if it's worth considering a mid-way point.

Swapping drum kits is currently hard in part because just loading them has a somewhat arbitrary order, and importing instruments individually inserts them as new instruments, so replacing them involves a clunky "copy notes all patterns" "paste notes all patterns" action.

What if it we allowed individual instruments to be imported as replacements by dragging from the Sound Library panel on top of the PatternEditorInstrumentList (maybe with Ctrl held down, or by being sensitive to the y position it's dropped on (on the middle part of an existing instrument, replace; closer to the edge between two instruments, insert. With an appropriate action preview, of course).

That would make the process significantly easier than currently, for probably less work and complexity, although nowhere near as easy as it would be to have a kit loaded and have it Just Work as your proposal.

[theGreatWhiteShark]

Hey, I'm afraid I can't give you any feedback (also not for the PRs) for at least one or two more weeks. It's flu season over here 😬

[theGreatWhiteShark]

Yes! Definitely.

or by being sensitive to the y position it's dropped on (on the middle part of an existing instrument, replace; closer to the edge between two instruments, insert. With an appropriate action preview, of course).

This (along with some other drag&drop features, like pattern and sample loading) is on my short list for possible 1.3 features too.

[theGreatWhiteShark]

Superseded by #1984