Any way to know the direction a fader is being moved?
It seems the faders are by default “absolute” in the sense that they go from 0 to 100 (left to right, invert) or 0 to 100 (top to bottom, invert).
Anyone ever found a way to know the direction it’s being pushed?
Would love for Traktor to get some programming language 
What exactly are you trying to do? Sounds like your planning something that would require the use of Bomes.
And yes, some sort of scripting language instead of that crappy midi mapping dialog would rock.
Was trying to have one side of the cross-fader do something, and the other side something else? (mainly, different deck focus)
Will look into Bomes, thanks!
To get the direction of movement, you need to take the difference between the current and previous value and, if the result is positive you’re increasing, negative you’re decreasing.
Keeping a copy of the previous value is exactly what Bome’s “global variables” are designed to do, and unfortunately Traktor has no ability to keep information around about the earlier state of a controller, so Bome’s is your friend here.
Interestingly, taking the difference between two values in a sequence is exactly the same as calculating the derivative of a discrete function (“discrete” because it comes in individual steps instead of being a continuous value). All the normal rules of Calculus can then be applied, so taking the difference will calculate the “velocity” (direction of change) of your movement and the difference between velocities will give you the “acceleration” (speed of change). This way you can tell not only which direction the controller moved, but also how “hard” you moved it.
Might be useful for putting some expression into a knob movement - tweak the filter cutoff in proportion to the speed of a change will give you an interesting “blurp” on fast movements. Not a convincing example, but something to play with!
Ive actually already written code for this in Bomes, let me see if i can dig it up 
This was made for the VCI-100 crossfader, but it can be reworked to work with any fader
Translator 1
Incomming : B0 08 pp
if g0<128 then skip next 2 rules
g0=pp
exit rules, skip Outgoing Action
if pp<g0 then skip next rule
Goto “Larger”
Goto “Smaller”
Label “Larger”
g0=pp
if g1==1 then exit rules, skip Outgoing Action
g1=1
pp=127
oo=94
exit rules, execute Outgoing Action
Label “Smaller”
g0=pp
if g1==2 then exit rules, skip Outgoing Action
g1=2
pp=127
oo=95
exit rules, execute Outgoing Action
Outgoing: 90 oo pp
Translator 2
Incomming: Project Opened
Rules: g0=128
Outgoing: None
If you find this code useful think about making me a dontation because you have absolutely no idea how on the bones of my ass i am at the moment.
He even includes the initial setup so there are no burps the first time you move the CC. That’s quality code right there. Bravo!
hah, Bento, your code looks almost exactly how I would recommend it. nice one bruva.
Thanks man, i pride myself on doing stuff properly
btw, fatlimey that code you were talking about of also having the knob accelloration is an awesome idea, im gonna play with that concept.
You might also want to investigate filtering the resulting velocity and acceleration values. Keep a rolling buffer of the last , say, 4 values and return the sum of them. This doesn’t work quite how you think it should as MIDI doesn’t generate events when there’s no movement, but it will tell you what the cumulative acceleration is.
The best filter would sum all events over slices of time, called buckets. Divide time into sections using a regular timer that fires a rule to move all buckets one step to the left. You then sum all the buckets. If you get lots of events in a burst you get a bucket full of events. No movement, you get an empty bucket. That’s proper time-filtered response with a quick ramp up as events flood in and a smooth fall off as the buckets slowly empty out. Just like VU meter falloff.
You can shape the falloff by doing a weighted sum of events. First bucket is 60% of the power, second bucket is 20%, third bucket is 8% etc, e.g.
A * 0.8 + b * 0.6 + c * 0.08 + …
Now you have entered the world of FIR (Finite Impulse Response) filters…
So I can write scripts for Bomes and don’t have to use this usability nightmare of a GUI? Should look into it again.
What exactly do you mean by that ?