"Intermediary midi mapping" software *discussion thread* (Traktor mapping is a pain)
Home :: Post and find Controller Mappings :: "Intermediary midi mapping" software *discussion thread* (Traktor mapping is a pain)Reply
"Intermediary midi mapping" software *discussion thread* (Traktor mapping is a pain) Posted on: 16.06.2011 by Arcelia Siebeneck IntroductionJust 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 believe 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 | |
| Chasidy Heckenbach 15.08.2011 |
Originally Posted by kostis12345
edit: unless running osx in a virtualbox type session would work... i'd still need to buy osx tho. |
| Jan Manzoni 15.08.2011 | Just a question, will this program be windows only or will it support other operating systems? |
| Chasidy Heckenbach 15.08.2011 |
Originally Posted by MiL0
i've got a slicer working ok but *sometimes* it gets confused and jumps the wrong way something to do with the beatphase i guess. when the beatphase resets to zero my code assumes the loop has jumped back to the start so pressing button 5 from there would need to beatjump +4 and not -3 which it would need to have done a fraction before if the loop hadn't jumped to the start again yet. guess i could not enable a loop and just send a beatjump when it gets to the end too but quite liked having the loop set as visual feedback in traktor. maybe no other reason for it. that the kind of beat juggling you meant or something different? and you want traktor to jump to the place it *would* have been had juggling not been done afterwards? only issue there is stacking the various indiv traktor beatjump commands together - as they seem to need a delay in between else traktor ignores them. |
| Arcelia Siebeneck 14.08.2011 | I reckon a good start would be programming a beatjuggler that automatically beatjumps forward to the position Traktor would be playing at, had you not started juggling beats (Serato style). |
| Chasidy Heckenbach 13.08.2011 | i also want to code a twitch style "slicer" before releasing the code. the problem there isn't that it's tricky to code, in fact it's far from it, the issue is that i'm still not 100% how/what/then the slicer should work |
| Chasidy Heckenbach 13.08.2011 |
Originally Posted by MiL0
i believe i'll come up with a couple of mappings for a lpd8 and launchpad first, since i'm sure a lot of people have those, with some midikatapult type sliders etc on the launchpad and a config for each of those controllers that emulates a midifighter in each mode as i'm pretty sure that'd be popular. i also want to write some kind of "getting started" documentation on my djism.com site so i can point people to that |
| Arcelia Siebeneck 13.08.2011 | nice one - looking forward to trying that out on my 2 x LPD8's |
| Chasidy Heckenbach 13.08.2011 | just found a simple solution to mapping an lpd8 pad to a "play" in traktor. the lpd8 has a nasty feature where it turns the led for a pad off when you release it even if it's received an external midi message to turn it on - like play_a in traktor. modded my toggle button function to check the current state when you release a button and if its set to ON then send that message back to the pad. so when you release an lpd8 pad it will stay lit if thats the current state. that was my only real gripe about the lpd8 - but seems its not so much of an issue so now this basically happens: * press a pad: ** if state was OFF then set to ON and send ON message to traktor ** if state was ON then set to OFF and send OFF message to traktor * release a pad: ** if state is ON then send the last ON message back to the pad to keep it on * message from traktor ** set the state and led status based on the message just won't work for PC mode as we don't get any message on pad release |
| Chasidy Heckenbach 11.08.2011 | just a quick update as this thread has been dead for a while now. most of the missing elements in my code have been implemented and the bugs i knew about fixed. with the xtreme mapping negates mostly the need for just something to simplify trakor mapping but that was only one reason for me coding this in the first place. one thing i have been playing with is using the note and cc modes of my lpd8 to act as a midifighter with midimasher doing the translation. works quite well and is hopefully a config i'll release here soon for people to try out. the prog change mode on the lpd8 isnt quite so useful as it only sends out a message when you press a pad so can be used as toggle buttons or triggers but not as hold buttons - but that still leaves a virtual grid layout of 4x6 where the top 4 rows can do anything and the bottom are a bit more limitted. i've been able to use some config code to do all that the darouter does for my scs.3d as well - so mostly been testing out the code with my launchpad, lpd8 and scs.3d and i'm sure a lot of people at least have the first two of those. |
| Chasidy Heckenbach 25.07.2011 | 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... |
| Chasidy Heckenbach 25.07.2011 |
Originally Posted by safefire
i am interested in maybe combining some hid stuff - but certainly won't believe 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. |
| Chasidy Heckenbach 25.07.2011 |
Originally Posted by MiL0
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: this next file functions.lua contains the functions listed after it.
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): 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. |
| Lewis Stumpf 25.07.2011 | 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 believe 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. |
| Arcelia Siebeneck 25.07.2011 | bump |
| Chasidy Heckenbach 20.06.2011 |
Originally Posted by fiddelfingerz
|
| Oda Duni 20.06.2011 | 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 |
| Allene Manitta 17.06.2011 | 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, |
| Chasidy Heckenbach 16.06.2011 |
Originally Posted by MiL0
|
| Arcelia Siebeneck 16.06.2011 |
Originally Posted by zestoi
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.
Originally Posted by zestoi
|
| Chasidy Heckenbach 16.06.2011 |
Originally Posted by MiL0
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
|
| Arcelia Siebeneck 16.06.2011 | 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 |
| Cammy Clegg 16.06.2011 | Milo do you know how to use Bomes? or know of a tutorial? |
| Chasidy Heckenbach 16.06.2011 |
Originally Posted by MiL0
so with your c++ app are you going to make it so that it imports an LUA file?
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?
do you plan on making it available to everyone? open source?
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... |
| Arcelia Siebeneck 16.06.2011 |
Originally Posted by zestoi
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? |
| Chasidy Heckenbach 16.06.2011 |
Originally Posted by MiL0
|
| Chasidy Heckenbach 16.06.2011 | 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: Code:
add_control("copy_from_loop_recorder_c1", 5, "cc", 24);
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: Code:
open_midi_device("nanokontrol", "nanokontrol", "nanoKONTROL", "nanoKONTROL")
open_midi_device("hercules", "hercules_mk2", "Hercules DJ Console Mk2 MIDI", "Hercules DJ Console Mk2 MIDI")
Code:
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)
oh - ramble over - hope some of that made sense - it's been a long day and am knackered. |
| Dana Ordinario 17.06.2011 | 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. |
| Arcelia Siebeneck 16.06.2011 | 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... |
<< Back to Post and find Controller MappingsReply