1. Hi everyone,

    Apple just released Logic Pro 10.5 for MacOS 10.15. We found out that Massive X, Crush Pack, Mod Pack, Replika, and Replika XT will crash.

    Our teams are currently working on a fix, and we hope to have this out to you as soon as we can!

    Best wishes, 
    The NI Team

    Dismiss Notice

Major Upgrade to add Functionality to Controller Mapping Settings

Discussion in 'Feature Suggestions' started by Jodi Curtis, Sep 7, 2016.

  1. Jodi Curtis

    Jodi Curtis New Member


    I'm a software engineer and I read a much about the power of traktor's mapping capability, and complexity.

    For a typical user it may be somewhat overwhelming in power, but coming from a software engineering background, NI seem to be massively limiting the potential for complex mappings, and while many may be happy, I think NI are doing a disservice to how excellent other parts of traktor are, and the controllers inbuilt flexibility if you get creative with the mappings

    The main issues which limit the power of a controller.

    1. Not enough global modifiers (this has been said before)

    My current mapping for the Xone K1, to manage multiple layers of functionality, after the first layer of functionality has used M5,M6,M7 and M8 (1 through four) M1 (0 and 5-6)

    2. Not enough conditions

    Two has done everything so far, but just one more condition would enable massively increased overlaying of functionality, it would also be a requirement for my next feature. 4 of these would be ideal.

    3. Store an internal state of the LED's, and then add the ability to check LED state within the conditions.

    Mapping multiple colours to the same Button depending on a state works until it comes to restoring the state (such as not losing track of an LED which indicated if the filter is on or off, after switching its colour from Orange to Red or Green, to indicate to the user that an encoder is currently controlling the filter. (red meaning filter is being controlled and is on, green meaning filter is being controlled and is off for example)

    The issue here arises when you use an out to clear the red or green state back to orange or off, without a LED state image which stores the orange LED as on throughout (even though it's been switched on the controller), you cannot determine which state to restore the LED to through conditions.

    4. Allow software state (such as filter on/off etc... to be checked as part of the expanded conditions)

    This presents an alternate way to working around the issue above, without storing LED state, but you cannot actively probe anything within the conditions accessible.

    5. Enable simple LED sequences...

    This could be via properties:
    a) target LED
    b) on or flash (once or twice per second)
    c) duration (1-5 seconds)
    d) end state off, on, restore (restore to pre-sequence LED state via feature 3, restore on software state condition via feature 4, restore via set modifier which would have an LED out mapping as a separate entry)

    Sometimes we just need a reminder of the state of the controller, this is one feature that would maximise the MIDI system and probably bring the feedback right up to the level of dedicated firmware feedback on groovebox style machines.

    I hope you'll consider some of these features, it could expand a controller massively and enable some really powerful features rather than watering down MIDI mappings with workarounds, and limiting functionality due to the modifier bank count

    Pipedream request...

    6. A future advanced mode which allows you to script parts of the controller mapping... maybe this is already possible


  2. Jodi Curtis

    Jodi Curtis New Member

    Edit, there are way's to accomplish 3 if you have enough conditions , with the LED switching from green off/on to orange off/on (for the Xone K1) and back again (in this case switching a play button to show master sync on or off, and back against depending on a global modifier indicating shift)

    I'll post an example solution which switches and restores LED state depending on Shift - once I've completed my mapping and cloned this bit of functionality into a simple example

    I'm hoping to use this for the use-case presented in the OP, but it's not a priority right now.

    This requires something like 6-8 entries into the mapping table (one in/out each for the two button functions, and at least two entries to clear LED state when shifting off the top of my head, but this may not be all of them)

    A two position software push/pop stack would be much more suitable, as LED use using the mapping system is really difficult, and would offer some powerful features where this type of solution cannot be achieved.
  3. dj_estrela

    dj_estrela NI Product Owner

    From a techical point of view, adding more modifiers, plus more states per modifier should be easy to implement, and solve a lot of problems immedialty!
  4. Dasuper

    Dasuper New Member

    +1, more modifiers and conditions that is a real must!
  5. nr1cristi

    nr1cristi NI Product Owner

    I think that the platform on wich traktor operates is somewhat limited to only this! ... the updates wich come from NI regarding traktor are relativly minor and no new features arise... I am guessing that this is the max state wich they can evolve in traktor... still i would focus on sound and Pc/Mac usage! you can do tons of stuff with the current mapping options and modifiers! still i agree with you guys!
    + 1 on modifiers and conditions.