Ean recently announced that work on the 3.0 mapping by DJTT for their very own VCI-100SE is commencing. He started things off my a survey of how current features are being used and where people want thing to go in the future. I guess the main theme Ean has in mind for now is pushing effect presets a bit more even going so far as to put one or two into the transport section. I know that Ean in general is struggling with Traktor's limitations in terms of modifiers, which is why I suggested moving to bitwise operations when checking modifiers. That being said as I explained in that forum post, that makes the already painful redundant mappings for double assigning features for 2 decks even worse. From the feedback on his blog post and forum posts it can also be concluded that reconciling the needs of all users is a mission impossible (no surprise really). Furthermore given the complexities caused by Traktor's modifiers and lack of support for modifiers in the device target that will only get worse if bitwise operations are adopted to increase the number of modifiers, it will become more and more painful for users to attempt to customize the official mapping. Especially if new updates come out which means people need to keep painstakingly accurate logs of all their changes outside of Traktor in order to reintroduce their customization if outdated official TSI's come out. As such I believe that we are now in a situation where we have to introduce another tool to the mix: aka Bome MIDI translator!
With Bome's Ean could move the entire modifier handling into a Bome's script which simply outputs different MIDI messages according to the state of variables stored inside Bome. Adjusting a preset in the stock TSI would now become a trivial process of just using MIDI learn to setup the alternative behavior. Suddenly anyone can make adjustments to the official TSI without having to even know about the concept of modifiers/variables let alone how they are implemented in the DJTT TSI.
However it gets even better. In order to be able to please all user types I have suggested splitting up the TSI into multiple modules. These modules would all use the same modifier setup. As a result one could have a module for an "echo-drop-cue-play" transport section but also one for "echo-slice-cue-play". There could be one mapping for the EQ section with "EQ-FX" and one without. There could be one mapping for the FX section that pushes presets, another one that pushes custom FX mappings and yet another one for loop management and users could choose which of the 2 they want to apply. In theory a user could have all modules loaded and simply set the ports accordingly to disable or enable a module, making it possible to optimize the setup for each section of the set being played currently. This is all possible with TP 1.2 out of the box: I have done a proof of concept for this Module concept.
However the annoying part is that there needs to be a mapping for most modules for deck A/C and deck B/D as well as FX 1/2 and FX 3/4 in order to be able to put all of TP's power into the limited number of controls on the VCI-100. This means a lot of additional work for Ean and/or reduced flexibility for end users. Say for example someone wants "echo-drop-cue-play" for deck A and B and "echo-slice-cue-play" for deck C and D. Someone else might want "echo-drop-cue-play" for deck A and C and "echo-slice-cue-play" for deck B and D. Maybe not the best example but I hope you all understand where I am going with this. With a Bome script this would no longer be necessary. There would need to only be a single mapping for each module. The idea being that Bome would push out the same MIDI messages depending on the modifier setting and the side of the VCI used. So while in the current mapping there are 4 mappings for each handling, 2 each on the same MIDI message but with a different modifier value, with Bome there would be only a single mapping. The beauty is that since Bome would send out the same MIDI message via a different virtual controller, we could use the device target feature in TP 1.2 to decide which deck should be affected by the message send. So in order to control 4 decks, all that needs to be done is load the same module TSI 4 times and assign the ports and device targets accordingly to get all 4 decks mapped. It would work the same way for the 4 FX banks.
So what would be the final result? There would be a single Bome script that sends out the same MIDI messages for controlling the decks and FX banks. There would be a TSI which contains all modules. Users would then duplicate the various modules assign the ports and device targets on the modules they want to use. As a result each user can mix and match all the different possible features. They can also easily add new modules or customize exiting modules without having to fiddle with modifiers at all. If changes are made to the TSI they need only update the modules that were fixed without having to reintegrate their own customizations unless they affected a module that was updated. DJTT could then even offer a repository for modules to allow even more "innovation at the edges". People that want to take things even further can of course also modify the Bome script itself.
Now obviously Bome MIDI translator is not free. A license runs 59 Euros. I think its a worthwhile investment but I think there is a way for us to bring down the price further. The guys behind Bome MIDI Translator also provide a "player" for OEMs that does not provide editing capabilities for the Bome script. But 99% of the users will not want make changes to the DJTT Bome script anyways. They can do all their customizations right in TP. The player is meant for OEM's that want to provide their users with the power of Bome without requiring them to get the full license. Their solution also enables OEM's to encrypt their scripts (not relevant for DJTT) as well as sign (maybe relevant for DJTT). I am not sure how much they would charge DJTT per player license, but it would surely be lower than the 59 Euros. I am sure there would be potential for getting a good deal, since DJTT users are very good potential up-sell candidates that might eventually want to upgrade to the full license.
PS: This might even make it possible to better support Firmware 1.2 users.
PPS: Of course if we all would start using Mixxx, we probably wouldn't need Bome in order to be able to get this level of easy customization.
PPPS: Using Bome's trigger functionality its also possible to have LED's blink, which can be used to visualize more states than just on and off as can be seen in my DJTT 2.2 modification.
PPPPS: It should also be easier to use the Bome based modules with 2 VCI's to control 4 decks on one machine by simply assigning the device targets accordingly and making some minor modifications to the Bome script.
PPPPPS: Using Bome would also enable better use of LED out messages like if a button already has a hotcue assigned.