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

[MiL0]

MidiMasher discussion thread (Traktor mapping is a pain)

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]

@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…

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]

@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.

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]

@MiL0

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.

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

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]

@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?!)

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.

[quote]
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 [/quote]

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.

[MiL0]

@zestoi

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.

seems loopMIDI allows for exactly that:

The driver is currently part of the rtpMIDI network-MIDI driver and the loopMIDI virtual loopback MIDI cable. But it can be used for other tasks as well. If you have a music-application that needs to create its own freely named MIDI-devices on-the-fly - virtualMIDI is exactly the right tool. In case your are interested, just contact me by email. A simple-to-use DLL-interface exists to create and destroy ports and to receive and send MIDI-commands, both for 32bit and 64bit.

virtualMIDI | Tobias Erichsen

@zestoi

nice being able to use the vanilla midifighter tsi’s tho.

yeah, that’s the main advantage in my eyes… being able to use the DJTT mappings without owning special hardware

[zestoi]

@MiL0

seems loopMIDI allows for exactly that:
virtualMIDI | Tobias Erichsen

awesome! i didn’t realise that… i’ll have to drop him an email.

[derschaich]

great project, guys, count me in! had something like this in mind for quite some time now, and i am very happy not to be alone on this now.

I have some basic c-scripting knowledge, and just read some LUA code for the first time, but it doesn’t seem too complex.

really looking forward to this collaboration!

btw: midi-masher sounds good to me,

[fiddelfingerz]

Just wanted to find out if you guys are still working on this. I have been looking around for this exact thing for ages. Super interested to see how far it has come

[zestoi]

@fiddelfingerz

Just wanted to find out if you guys are still working on this. I have been looking around for this exact thing for ages. Super interested to see how far it has come

only first started work on it a few weeks ago, so yep still working on it. still going to be a couple of weeks before i release any kind of beta level download most likely. work is hectic atm so not too much free time.

[MiL0]

bump

[safefire]

Read through (most) of this.

I have had something similar in mind for quite a while.
I wanted to incorporate a layer of mappability into my controllers, so that they could be mapped to whatever software one wanted as well as one could map them to Traktor. Maybe done in software, to also allow one to take in OSC data and commit modifiers across multiple controllers.

This would be brilliant if done, but if I might add one suggestion…
Please please PLEASE have a go at decoding the HID protocol Traktor uses for native controllers. That way, taking in OSC data could possibly allow for much higher resolutions than midi, while still remaining mappable.

I think this is a very valid enterprise. If one looks at the most recent controller from Native Instruments, the S4, which is mapped via hard-coded firmware and HID, completely circumventing Traktors MIDI mapping system, it becomes quite clear that the MIDI mapping systems needs a serious revamp.

[zestoi]

@MiL0

bump

oops… must admit i did think posting info on that other thread was a tiny bit OT of me and did think about this one after

this is the traktor.ua file i am using that binds lua functions to those in traktor with a tsi i have built with all the same stuff in, i’ll dump the tsi here too later:

• http://djism.com/lua/traktor.lua

this next file functions.lua contains the functions listed after it.

• http://djism.com/lua/functions.lua
• create_button()
• create_toggle_button()
• create_yfader()
• create_midifighter()
• create_midifighter_4banks()

the last 3 ofc can only really be used on some kind of grid controller - or at least a controller that has a group of buttons that can be treated like that etc.

The next files define controllers - these two are the main ones i have been playing with, i.e: one grid controller and one non-grid. no one really needs to tweak these either - unless they have them setup differently somehow (like maybe with an lpd8 etc). also i have a ‘learn.exe’ that lets you press a button on the controller and then type in its name ala traktor sort of - so mapping a new controller is quite easy (most of the time):

• http://djism.com/lua/launchpad.lua
• http://djism.com/lua/hercules_mk2.lua

the code actually treats traktor no differently from any controller - they are all just devices that can comunicate.

i’ve made pretty crap progress the last few weeks but have also bought a bunch of controller since then so really really want to find some time to at least add in some missing features into the system and then get to mapping all my new ones and starting to figure out more what kind of setup is right for me.

[zestoi]

@safefire

I have had something similar in mind for quite a while.
I wanted to incorporate a layer of mappability into my controllers, so that they could be mapped to whatever software one wanted as well as one could map them to Traktor. Maybe done in software, to also allow one to take in OSC data and commit modifiers across multiple controllers.

This would be brilliant if done, but if I might add one suggestion…
Please please PLEASE have a go at decoding the HID protocol Traktor uses for native controllers. That way, taking in OSC data could possibly allow for much higher resolutions than midi, while still remaining mappable.

not sure about the hid protocol from ni - i dont have any way of testing that. currently my code is based around an open source midi library (RtMidi) but there’s no reason why it couldn’t also connect via hid i guess - but would probably need a developer with access to stuff to test with. the only hid libs i have seen have been windows centric but i’m sure (?) there must be one that works on mac/linux too?

i am interested in maybe combining some hid stuff - but certainly won’t think about that until some missing features have been added and it all works using midi.

so far my code should work on any of winblowz/mac/linux tho must admit i havent actually compiled it under linux yet and dont have a mac anyway. the only linux app i have really tried is mixxx - tho the mixxx controller mapping stuff is already light years ahead of traktor and probably wouldn’t need it. i just prefer traktor - shame it doesnt run on linux.

[zestoi]

pretty OT but i was pleased to grab djism.com to use for publishing my stuff on. i noticed it hadn’t been renewed and grabbed it for reg fee when it finally dropped a nice one to add to my portfolio anyway…