This is the world's smallest DJ soundcard for Traktor DJ and Traktor Pro 2. Now you can pre-listen to the next track for flawless mixes with pristine, punchy 24-bit/48 kHz pro sound quality. Cypress touchpad driver windows 7 64 bit. The Native Instruments Traktor Audio 2 MK2 DJ interface transforms your laptop or iOS device into a club-ready DJ rig! Note: If you own a TRAKTOR READY controller, the configuration is done automatically via the Setup Wizard and you may skip to this article. Adding a Mapping for Your Controller. In order for your controller to interact with the TRAKTOR software interface, you need to add a MIDI mapping (Device) to TRAKTOR's Controller Manager. Combine all this with a high-quality, 24-bit/48kHz audio interface and Traktor Pro 3 DJ software, and the Traktor Kontrol S8 is a performance-ready DJ controller. Learn more about the Native Instruments Traktor Kontrol S8.

2009-07-25 3:36 pm1 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 Steam universal access for app on mac bugs bunny. , 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.

Traktor Midi Mapping

Best Midi Controller For Traktor Pro 2 Download

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.