Traktor Pro 1.2 beta opens a world of fun

1 Comment

I am quite thrilled about what NI has done in Traktor Pro 1.2. The introduction of logical controllers in the MIDI mapping opens a world of fun for MIDI mapping junkies. It also enables much better collaboration because mappings can be maintained in smaller logical units, so there is no need to maintain a single monolithic configuration for all controllers anymore. Since each logical controller also gets its own modifiers we now also effectively have unlimited modifiers. The addition of a tool that shows the current modifier states will also become an invaluable tool. Several other additions are also welcome be them small or big: Preparation list management now seems much more useable, 2 additional FX controls will certainly be useful even if just "misused" as a sampler, 3 new effects (I especially like the beat slicer), being able to show the comments in the deck details really helps out when using DJ notation. Again the biggest thing for me are the changes around MIDI mapping, which are a huge step forward I hope that NI gives them a few more bits to make them truly useful. Rainer has already started on an update for the Traktor Pro Bible.

I have long been complaining about how the current MIDI mapping in TP 1.1.x makes collaboration needlessly hard. Since everything sits in this gigantic monolithic configuration, which when exported is not human readable, it meant that there was no sensible way to share only parts of your config. Changing one area brought with it the huge risk of being incompatible with others who used the same starting point. Now with the logical controllers, I can keep separate mappings for each of my controllers, I can actually even have multiple logical controllers for each bigger feature. Furthermore I there is no longer a need to worry about what channel my controllers are working on, since for each logical controller I can decide which MIDI controllers it should listen to.

I am still missing a few critical things and a few new issues. For example I dont like that the mapping for In and Out assignments has been separated. This means I cannot just duplicate an In mapping and turn the duplicate into an Out message to also change an LED accordingly. Actually when duplicating the associated MIDI message is lost now. Furthermore Out mappings do not support MIDI learn anymore. I am hoping these are all just bugs that will get fixed.

There are a few issues where I think the new features need to be expanded a bit more. For one since each logical controller is totally separated from the others, it means that if I have common states in the various logical controllers (say a toggle to select deck A or C/B or D), these need to be duplicated for each logical controller. Also keyboard or HID logical controllers now have no way of interacting with MIDI logical controllers, since the modifiers are all separate. It would be nice if next to the local modifiers, there would also be global modifiers in order to be able to communicate such states across logical controllers. This should not be too hard to implement I would think.

More fancy would be a way for logical controllers to "include" other logical controllers. This way I could make one logical controller that manages the deck selection by setting the relevant modifiers and LEDs. Now in my other logical controllers I could say that the deck managing logical controller should be included. This way even with just a single mapping for the deck management, all relevant logical controllers would set the proper modifiers locally. This would also make it possible to group logical controllers. For example my VCI-100 logical controller would consist of several "sub" logical controllers. Could be useful to stay on top of what is used where and more importantly making sure that when exporting, I can easily ensure that all relevant "sub" logical controllers are also exported.

I am also wondering how to best do a 4 deck mapping. Lets imagine I have 2 controllers that handle 1 deck each. I would do one mapping which I can now easily import twice in order to handle 2 decks. However if I want to handle 4 decks, I would run into trouble. I would have to duplicate the mappings to handle the modifier to switch the left deck between deck A and C (and deck B and D on the right side). Worse yet, I do not see how I could make a generic deck mapping to handle deck C and D using the device target without making it impossible to also be able to run all of the possible combinations of decks. So I could do A+B or deck C+D but not A+D or B+C. The solution would be to allow choosing the device target based on a modifier. This way I could have one mapping for all 4 decks and support all deck combinations. The same feature should be available for selecting the FX bank so that a single mapping could be made to handle all 4 FX banks.

Once we have that, it seems like 2 deck controllers like the VCI-100 would be at a disadvantage to 1 deck controllers in a way. With the VCI-100 I would be forced to map out the left and right side separately, since they send different MIDI messages. Well I could use Bome's to transpose the MIDI messages and send them via different virtual ports. Alternatively hardware producers could think about providing different modes for their 2 deck controllers. One where they send different MIDI messages as they do now and one where they turn their 2 deck MIDI controller into 2 virtual controllers that send the same MIDI messages for both decks. Of course this can be done in existing controllers already even without a firmware update using Bome's MIDI translator.

Now comes one of my pet peeves. Unfortunately the exported configuration remains human unreadable with no formatting at all. This means its still impossible to figure out what one has actually changed when comparing two versions of a configuration file. On top of that there is no undo/redo feature, so when one works on getting a new feature to work, its easy to loose track of what has actually been done, which can often lead to unwanted changes and bugs due to experimentation. With the addition of logical controllers at least its easier to keep the number of mappings per controller down, so its a bit more possible to keep an overview of all the mappings and hopefully notice accidental changes. However with the crappy output format its still impossible for me to receive someone's modifications and be able to see what has changed. Take Ean who publishes fairly complex TSI's on DJTT, lots of people like it and then someone suggests a tweak and sends me a modified version. Trying to figure out what has changed is very tedious. Actually its short of undoable without two laptops next to each other. Managing the configuration inside a version control like svn is also a lot less useful as things are now.

The window size for the preferences is still limited and non resizable. If it would be an easy fix, I am sure they would have done it by now, but I am guessing they have an architectural issues with their underlying window management toolkit. However I think the best course of action would be to provide an optional standalone MIDI mapping app. This app would provide the much needed real-estate for working on more complex mappings. It would allow much more flexibility in interaction. Like say I want to cut several mappings and move them into a different logical controller. Or I want to change the channel on several mappings. Actually just simple stuff like being able to search the MIDI assignments would be a huge help! It could also provide a TSI merging and comparison tool. Debugging tools could be expanded to also provide a logger for all messages and maybe even some visualization for what message is interpreted by what logical controller and what is executed as a result. Maybe there could also be a little community feature to allow exchange of mappings. Obviously this will also mean that features in this app can be expanded without worrying DJ's that their audio setup could be affected as its a separate app.


You are sick. Brain-sick to be precise. Hahaha, mapping editor, by NI....hahah, they can't find their ass in the traktor source and you are requesting another app.
How does a brain-sick DJ write such a nice article?
I like the ideas and solutions. I think I'll start following your rant.
I have another addition to your wish list:
- detect different multiple keyobards like you detect controllers, or else...

2009-07-25 8:21 pm

You do not have permission to comment on this site.