Regardless if the XML editing is supported, or not, the functionality that we are asking for is here. It’s not about “more powerful”. It already is very powerful and completely sufficient. We just don’t have (or know) a way to set modifier states. But the application is very close to provide a complete Out Of the Box Support.
Going over many mapping files, I see this:
- Most controller mappings use “modifier1-4” for the PadMode state of the 4 decks, but not all.
- Most controller mappings use “modifier5-6” to track if Deck1 or 3 is selected on the left side in modifier5; and if Deck 2/4 is selected on the right side, but not all.
- Mixtour is using modifier1 for tracking if the “FX” button is pressed to do the conditions logic for when FX mode is selected and the FIlter know would become FX1 parameter control.
- RANE Performer mapping is build with a more meaningful names of the modifieres: “PadMode1”/“PadMode2”/ertc for the selected pad mode of the 4 decks; The selected decks are tracked as “LeftDeck1”; “RightDeck2”; “LeftDeck3”; “RightDeck4” with values of 0/1 indicating which is selected, instead of the modifier5 & 6 approach across the majority of the mappings.
- the PadMode values in modifier1-4 also varies between the different controller mappings.
- There already is dual conditions support with the keywords “AND” and “&&”;
- There already are equal “==” and does not equal “!=” operands.
While there are similarities in how controller mappings are implemented, there’s apparently no strict/fixed convention. The names differ, the values too. Yet, the approach is very similar across the controllers and in my opinion, a very nice way for “modifiers” functionality - I really like it, and it’s already here and working. Very little extra is needed to make it available to us.
If only selecting a PadMode through the MIDI command would rise/alter a modifier state, it would be great, and we can do anything with mappings. There are 21 distinct MIDI commands for Pad Mode Select. 21 modes per deck! They are already implemented and all it would take is to also set a unique number value in a correspondingly named Modifier name (similar to modifier1-4, or PadMode1-4) upon selection. Once we have this, we can do virtually ANYTHING within our mappings and have all the needed layers available to map anything. Of course, as the names modifier1-6 are already in use across the legacy mappings, the names have to be different but e.g. “DeckPadMode1-4” is probably not in use by any controller yet, and available for an OOB use.
Of course, I realize that due to the variations of the existing mappings, backward compatibility has to be preserved. There are about 183 stock mapping files in the application as Nov 2024. IMO, it would be an unnecessary overkill and unneeded to make them consistent. The much higher value for us would be to just have ability to work fully with them, regardless of the naming conventions used historically.
Please consider enhancing the per-deck “Select Pad Mode” MIDI action to also set a state in a modifier name “DeckPadMode1-4” (or similar), that we can use as condition for building advanced multi-layer mappings. We can do everything with our mappings if the app just does this small thing.