"Intermediary midi mapping" software *discussion thread* (Traktor mapping is a pain)

[MiL0]

Introduction

Just wanted to start a discussion thread regarding the shortcomings of mapping midi controllers using Traktors default mapping options. And by that, I don't just mean the annoying non-resizeable window, lack of serious copy/paste/clipboard functions and the recent inablity to directly edit the xml mapping files with a text editor. What I'm really talking about is the limitations of the default Traktor midi mapping window to achieve more powerful, dynamic and complex mappings... mappings that go well beyond what Traktor is normally capable of.

So what do I mean by this? Well if we look at the djtt firmwares for the vci-100 and midifighter as an example you can see that Traktor is capable of some amazing things. Superfaders, fx triggers, etc are made possible by combining various midi commands into one control which are then executed in a certain way. The only realistic way to achieve this is by re-writing the firmware on a midi controller at a hardware level. Yes, it's true that some of these effects can be done via a plain old Traktor mapping - but it gets very complicated and isn't as full featured.

The obvious disadvantage with using modified firmwares is that only a few people have the skill and know how to write them. Also, the firmware will only work on specific midi hardware. What I propose is some sort of intermediary midi software that sits between Traktor and your hardware. A utility that allows full access to every midi command available in Traktor with the aim of achieving the kind of custom mappings only normally available via custom firmwares.

The solution

This isn't an easy undertaking so I'm hoping that the clever people on DJTT can get involved in the discussion and hopeful development of such a tool. In the absence of any sort of Traktor public SDK, here's how it could be achieved:

Traktor - A mapping is created that maps literally every control to a different midi CC. All these controls are set to receive midi from a virtual midi device such as LoopBe. The midi commands are then routed via LoopBe from the mapping utility which could be created via one of the following programs:

Synthmaker/SynthEdit - Both Windows programs which allow the creation of midi plugins/vst's. Usually the plugins are effects/synths for DAW's such as Cubase, Ableton Live, etc however they can also export standalone Windows executables with midi in/out functionality.

Reaktor - Same as Synthmaker/Synthedit but probably more powerful and there may be more people on here that know how to use Reaktor properly. Trouble is, I don't think there's a plugin export function so you'd need to run Reaktor in the background.. not ideal.

Emulator - the new version of Emulator allows you to design your own touchscreen interface GUI and map midi commands to each button/control.

GlovePie - probably quite a good option as their is decent scripting and midi support. Disadvantage is that it's a bit unstable in my experience.

Autohotkey - my area of expertise (lol) but not really designed for such a job... I might use it to knock up a prototype though.

VisualStudio - probably the most viable and professional option... a decent programming language that is stable, fast and powerful.


So what would the custom midi mapping software look like? and what kind of things could it do?

This is obviously up for discussion, but the first and most important function should be a wholesale replacement of the standard Traktor mapping window. The tool should allow easy duplicating, adding, deleting, etc of all the various Traktor controls and the ability to setup modifiers etc.

Once this is implemented, we can look at ways to achieve complex midi mappings based on rules, scripts, etc. This might enable functions such as superfaders and other midifighter features but also:

- complex ADSR/LFO based controls
- sequenced/pre-scripted midi control
- Serato-style continuous play in the background after beatjuggling has ended
- GUI editor for custom diy controllers (edit the midi controls in a more visual manner)
- simpler midi LED mappings
- stuff I haven't even thought of...!

How you can help

Feel free to contribute to this thread... let me know if this is something that you would find useful and what you would do differently. The suggestions I've listed above are just ideas and I'm keen to get something developed that will be useful for everyone so get posting

[MiL0]

of course, the other option is to try and decrypt the new Traktor xml files so that a 3rd party utility can open and edit them. Obviously this wouldn't allow for any of the other stuff I mentioned though...

[bartboy]

The problem with using third party software is the software itself ups the chances to crash it/traktor/system or any combination of the three. Add on top of that code that code that if not written properly could do the same thing.

I know a lot of people use all of those solutions without problems but most of us are not willing to run the risk they involve. I wish it was easier to create hardware solutions like super faders and combos but I find traktor to be the best djing program when it comes to programming controllers. The crappy interface aside. My hope is that companies will start writing these things directly into the harwire much like the midi fighters. Just my opinion.

[zestoi]

this is spooky.... this is *exactly* what i've been working on the the last few weeks. i wanted to not have to use the controller manager - have multiple banks/pages for any control surface and also to be able to use the same one (launchpad in this case) for both traktor and ableton.

the actual app is C++ using a cross platform midi library (RtMidi) and an embedded LUA interpreter for cool/custom stuff...

i havent mapped *all* traktor functions - but a lot - i didnt map decks C+D or sample decks A+B for example. as a) i wont be using them and b) it was really boring creating that tsi...

i have a devices/traktor.lua file that maps the tsi to names like this:

    add_control("copy_from_loop_recorder_c1",       5, "cc", 24);

it has 556 entries at the moment - so not exhaustive but enough for me to get started with.

the idea is i can route from any device/cc/note to any other device/cc/note and/or attach some lua code that gets called when the event comes in. i am using loopBE to create all my virtual midi ports - including 2 for traktor for that 2 way comms.

the upshot is that i use lua code to configure the mappings and when an event comes in it either gets processed directly by the C++ core if a simple routing etc or some lua code gets called to process it. so far i cant tell any latency issues due to the lua callbacks which was my concern initially - but i wanted a lighteweight embeddable scripting language that was flexible enough to do anything i needed.

the app first looks for a config.lua that loads up devices - which map midi ports to names like this:

    open_midi_device("nanokontrol", "nanokontrol", "nanoKONTROL", "nanoKONTROL")
    open_midi_device("hercules", "hercules_mk2", "Hercules DJ Console Mk2 MIDI", "Hercules DJ Console Mk2 MIDI")

then i can put calls to capture_event() in the config to specify callbacks for different events and/or use higher level functions like these two:

    create_yfader("launchpad", 0, 7, {1,2,3,4}, "launchpad", "solo", 8, lp_lo_red, lp_mi_red)

    create_midifighter("launchpad", 0, "midifighter", 2, 2)

also it keeps track of virtual pages for any device if specified in the config file.

oh - ramble over - hope some of that made sense - it's been a long day and am knackered.

[zestoi]

of course, the other option is to try and decrypt the new Traktor xml files so that a 3rd party utility can open and edit them. Obviously this wouldn't allow for any of the other stuff I mentioned though...

i spent a bit of time looking at the tsi's but not toooo much. plus we don't know if they're going to change the format again in the future etc ofc.

[MiL0]

this is spooky.... this is *exactly* what i've been working on the the last few weeks. i wanted to not have to use the controller manager - have multiple banks/pages for any control surface and also to be able to use the same one (launchpad in this case) for both traktor and ableton.

the actual app is C++ using a cross platform midi library (RtMidi) and an embedded LUA interpreter for cool/custom stuff...

i havent mapped *all* traktor functions - but a lot - i didnt map decks C+D or sample decks A+B for example. as a) i wont be using them and b) it was really boring creating that tsi...

i have a devices/traktor.lua file that maps the tsi to names like this:

    add_control("copy_from_loop_recorder_c1",       5, "cc", 24);

it has 556 entries at the moment - so not exhaustive but enough for me to get started with.

the idea is i can route from any device/cc/note to any other device/cc/note and/or attach some lua code that gets called when the event comes in. i am using loopBE to create all my virtual midi ports - including 2 for traktor for that 2 way comms.

sweet! great minds think alike

so with your c++ app are you going to make it so that it imports an LUA file? Will there be potential to develop the c++ application into something more visual and user-configurable than an LUA script processor?

do you plan on making it available to everyone? open source?

[zestoi]

sweet! great minds think alike

i figured someone else must have been thinking along the same lines.... whether that means great minds or not is another matter ofc

so with your c++ app are you going to make it so that it imports an LUA file?

pretty much. i chose lua for the config format as then it can be as simple or as complex as needed. i hadn't even heard of lua until a few weeks back - but as far as scripting languages go it seems to be about the easiest to get into but also has some pretty advanced functions that makes it very suitable. it's also designed to be embedded and lightweight - its used in some way world of warcraft i think (not that i play but my better half is an addict)

the C++ core stores the pages/banks/etc and handles routing midi data as configured up front by the config.lua file and optionally routing events to lua callback functions if needed etc. at runtime it tends to ping pong between the core and lua code - as the C++ code exports various functions that can be called by lua and vice versa.

Will there be potential to develop the c++ application into something more visual and user-configurable than an LUA script processor?

that could be a good plan. i don't have plans that way atm - but i don't see why not. would be tricky to make it as flexible as custom lua code but there again 99% of the time people should just be able to call high level functions (from lua or configured via a gui etc) to do what they need.

do you plan on making it available to everyone? open source?

yep - that was my plan. if i monetized it it would just end up feeling like another work project anyway which i don't want as a guess it'll be a few weeks tho before i release anything due to work loads atm - but you never know...

first i was confused at traktor mappings - then they made sense - then i realised how much i hated the controller editor - then tried midikatapult - then realised it had too many limitations and figured i couldnt afford to buy the bomes api - so thats why i started this...

i'm still very much a traktor noob tho - so finding my way as i go along - upgraded to traktor pro 2 almost exactly a month ago. traktor does seem awesome tho not that this app is (or should be) in any way limitted to traktor...

[chrisw]

Milo do you know how to use Bomes? or know of a tutorial?

[MiL0]

I wonder how easy it'd be to incorporate a built in LoopBe virtual device into the c++ (like Emulator does). That way Traktor would (at least appear to) directly talk to your LUA script processor tool (has it got a name yet?!)

I can't wait to try it... first thing that comes to mind is emulating all the midifighter combos etc... this way, pretty much anyone with a 16 button controller could use the superfx triggers etc

[zestoi]

I wonder how easy it'd be to incorporate a built in LoopBe virtual device into the c++ (like Emulator does). That way Traktor would (at least appear to) directly talk to your LUA script processor tool (has it got a name yet?!)

no clue on a name... have been calling it midimasher - but thats not very original... built in virtual midi devices would be cool. loopMIDI is great - but would make the config simpler - or at least less confusing in some ways.

I can't wait to try it... first thing that comes to mind is emulating all the midifighter combos etc... this way, pretty much anyone with a 16 button controller could use the superfx triggers etc

i already have code that emulates a midifighter in normal and 4banks mode - just haven't added the super combo's in yet, will be doing that very soon tho. the virtual midifighters work fine on my launchpad - and could add 4 on one page if wanted - not that theres any need for 4 ofc... nice being able to use the vanilla midifighter tsi's tho.