(Traktor: Multi Function Button) The working list of bad combos and workarounds

(Traktor: Multi Function Button) The working list of bad combos and workarounds

Moving the topic some members and I were discussing here: http://www.djtechtools.com/forum/showthread.php?t=39118

Have you ever ran into situations where a single button that you set up to do multiple things fails half way through the list of commands, or discards the first command and just does the second, etc..?

  1. Traktor tries to complete the commands “as if” they were done simultaniously, all at the same time. (pseudo-simultaneity)

  2. If your list of commands is something that cannot be done at the same time, it takes priority in the command that you mapped last.

My goal is to come up with a universal method that doesn’t rely on an external application (edited) to assign as many commands as you’d like to one button (as long as it’s meant to be a simultaneous event), but if all else fails, I will try my best to confront each issue separately.

So, please submit any combo that you tried mapping to one button without success.

Some examples are:

FX Panel mode to Single / FX Select (only the panel mode changes)
Deck Flavor / Deck Size (only the flavor changes)
BeatJump +2/BeatJump +4 (only jumps 4 beats. Not 2, not 6)

The above three all have a workaround.

There’s a blog post that was put up earlier this month:

Seems like this could be of some help. :B

Thanks! :slight_smile:

It’s great that you brought this up for me because I forgot to clarify that I was aiming at a method that doesn’t need an external tool, so I updated that bit on my original post. The DJTT method is really neat and I know it’s capable of things that NI could get away with saying “well, we don’t mean to design our software that way”. My current goal is to get things that seem they ought to be doable in Traktor, to be done so.

Press the button twice.

Dude… who would have thought of that…

Wait, shoot… That doesn’t cut it for the beatjump example.

AFAIK the order in which you map commands is not a factor in the order they are executed.

As far as I know, you’re absolutely right.

It only matters when:

  1. Each of the commands are doable at that exact moment, but
  2. they cannot both be done – one contradicts the other

in which case, it will do the one mapped last.

yep, it does seem to matter sometimes and also that sending in multiple midi messages without any delays between acts in the same way. would be worth putting down a list of what we think we have worked out so far. u said you had solved the “change fx panel mode && set effect”?

Yes. I can beat jump 6 beats too. No modifiers. It’s so simple you would get mad at me for keeping you in suspense.

Before that, I want to jot down another finding.

I am currently working on verifying my pseudo-simultaneity theory.

According to the theory, Traktor does it’s best to make everything happen in the now.

So, if you map these two -

modifier#1 /set value to 1/ when M1=0
modifier#1 /set value to 0/ when M1=1

-you get a button that toggles the modifier state from 0 to 1 to 0 to 1…

And then if you map to the same button something like -

beatjump +4 /when M1=1

If the modifier state is 0 when you press it, since Trakor tries to do whatever it’s told to in the now, it will just change M1 value to 1.

The next time you press it, since now M1=1, it will beatjump 4 beats, as well as change M1 value to 0.

Here’s where we run into some problematic behavior, that if used with some creativity might actually serve as a neat function.

if you mapped to the same button instead of beatjump -

CUE/deck A/Hold/when M1=0

-and if you press the button when M1=0, the deck will start playing (you’re holding the cue) BUT releasing the button won’t stop the deck because when the MIDI signal that you released the button is sent, M1 has already changed to 1.

Okay… so how do we make good use of the bug, I mean, function? I don’t know yet, but I’m really excited that I am starting to see some consistency in Traktor’s language.:roll_eyes:

Another way around the problem is mapping to a knob or fader. Because you are sending out the commands from 0-127 moving the knob/faders few clicks sends the msgs more than once so it seems to happen all at once.

Pushing a button twice is what I do for super buttons where the first click loads the fx or changes the slot from adv to chained ( or the other way round) the second finishes loading fx or setting parameters and activates the fx.

Always wished it would do it in one push

Very interested in your findings. Keep the info coming.

:stuck_out_tongue:

but that is just expected behaviour surely, that is the standard way to implement a toggled modifier in traktor?

when u have two enties one with condition of M1=0 and one for M1=1 then they don’t fall into the whole “are they processed in order or all at once” thing surely anyway?

Yes.

And regarding your super button… from what I’ve found so far, is the toughest nut to crack. You want the button to activate the effects in “Hold” interaction mode right? There is a one-push method if “direct” or “toggle” works for you.

To get a “panel mode changing & XXX & YYY & ZZZ & Fx on (Hold)” button without an external application, I can currently think of only three ways.

(1)THE FADON

What the hell is that? It’s a conceptual switch that interacts with the human as a button, but sends a volume-like message of 128 steps from 0 to 127. A really short fader placed perpendicular to the surface of the button.
(c)DJ MiCL

(2)Or the good old two-step switch you can find on camera shutters. Sends first midi while your pressing down and sends second midi when it hits the bottom. I’d think that some drum pads already have similar functions?

(3)Game Pad Buttons. When I was messing around with custom HID, I noticed that the game pad buttons sent variable signals rather than a 0/1. Swapping your super-button’s button with such a button might be a fairly DIY-able method…

Yeah. All involves fixing the hardware so it’s not really a satisfactory solution.

Well, I’ll keep working on this!

I know! I didn’t mean that… Let me explain.

It’s very relevant to this thread because prior to my awakening, I was asking all the wrong questions… namely, “When two commands are assigned, in what order does Traktor handle things?”

Granted, it could be (I doubt it) that in the previous combo (1) Traktor checks Modifier Condition, then (2) enters the CUE-activated state, then (3) changes the Modifier state to 1, then (4) upon release it does nothing because it’s not in the state required for the button to function as a CUE button.

There is no logical reason for (2) to happen before (3), except that it is a more desirable behavior than the other way around. In a mindset that allows me to think Traktor chooses to do things in a certain order, we run into situations where Traktor is seemingly getting it all wrong. In another instance when Traktor seemed to be fumbling with events that could have happened in either order and get the same results, we needed to introduce the “necessary 3ms delay” theory.

I laid it out just as an example that I can explain everything based on the “pseudo-simultaneity theory”, with much more simplicity and without the worries of whether Traktor gets it or not, nor when Traktor needs a break between two events, etc…

i’m sure internally in traktor it’s very big kind of event driven set of cascading rules built from the tsi. no events come in simultaneously ofc over midi, from the same device anyway. so it seems to be deciding what to do based on what it’s already received within the current “time slot” (2ms or so) and it’s current state. it is interesting about changing the order of items in the tsi and adding in the small delays tho, that we can change it’s behaviour. still a pain tho…

escapemcp, Zestoi

Sorry I kept you in suspense, I had to make this video…
It may not even be anything new, either, but it can solve my FX panel problem, escapemcp’s Deck Size problem, and the 6 beat beatjump to some extent.

I will be back with more later.

very cool video but just a tiiiiiiiny bit over the top :smiley:

cunning idea basically layering two controls, one of which is direct with invert set - even tho u shouldn’t be able to set invert. i just tried it by going to ‘reset’ and clicking invert and then setting back to direct and u can def layer an fx panel change + fx select with that method :slight_smile:

sadly doesn’t fix my issue as i need the fx select command to be of type ‘fader’ which uses the invert for something completely different ofc. there again i could add 4 extra controls - one per fx unit - just for the gater command which would at least make my post faderfx code work better - or ofc add one per each effect per fx unit and send a different midi message per fx as opposed to velocity.

the beatjump is really interesting too… normally you can’t set invert for a beatjump in direct mode but if u change it temporarily to a fader u can.

i just added a +4 followed by a +2 to a single button and it worked fine :wink:

i wonder how long the average button hit takes? i.e: how long between hitting and releasing? as traktor won’t process the inverted event until the button is released ofc - which adds in the time interval that is basically why we had to add the delays in before.

just checked using my lpd8 who’s pads are fairly quick i guess and the demo code that comes with RtMidi and it shows my pad times between 20ms and about 60ms. this is ofc a lot more time than the small delays i’ve been adding in via midimasher, so the beatjumps etc won’t seem quite so clean BUT u can do it in traktor without extra software :slight_smile:

cheers for the info MiCL :smiley: before i thought it just wasn’t possible “at all” to map two things like 2beatjumps or fx panelmode+select to one button but at least, with some caveats, it seems it is possible - awesome :slight_smile:

i’m sure we guessed this anyway, but the limit on how close the ON and OFF messages can be so that the invert action gets triggered (or rather so the non-inverted one isn’t ignored) is still 3ms

just used this little config to test:

open_midi_device("lpd8", "lpd8", "LPD8", "LPD8")
open_midi_device("loopbe", "generic", "", "LoopBe Internal MIDI")

capture("lpd8", "3,3", NOFF, 0, function(d,e,v,p)
send("loopbe", "CC004", ON)
msleep(3)
send("loopbe", "CC004", OFF)
end)

it’s a neat solution tho - using the inverted option for the second event… it does make some stuff possible that wouldn’t be without middleware software - the user just needs to be quick with his fingers on releasing :wink:

No fair! You can’t accuse me for not solving something I never guaranteed I could. Plus I never heard your issue specifically (or did I?) anyway! :rage: Tell me what it is that you need to accomplish and let’s see if I can’t tackle it!:slight_smile: Try me!

Those results are very promising… I think 20 ms is fast enough to capture most of the transient after the jump & the DJ could train himself to tap the pad just a bit sooner (10 ms or so) to get even better results.

That being said, simple merging of two events that involve playhead moving is not one of the strong features of the “Inverted Direct”. And obviously it’s totally incompetent when it comes to multiple commands you want to execute in Hold mode. (e.g., FX panel mode + FX on Hold)

Rather, the true greatness of the “Inverted Direct” is just that - Inverted Direct. This was thought to be impossible, but it wasn’t, and if you let your creativity play with this idea a bit, you will most definitely come up with some really cool usages of this feature. Momentary interaction (like the CUE button) was always possible, but it was only between the values 0 and 1. The Inverted Direct opens up the door to all the values in between!!

You can say that again!

Zestoi, you remember the experiment you did that resulted in 90 % success when the delay time was 2 ms?

That made me start thinking. How could it be that there is a fuzzy line between Traktor interpreting a couple of events as “simultaneous” or “consecutive”? Then it struck me.

The Frame Theory

The theory says Traktor chops up time into frames and handles events Frame-by-Frame.

Let’s assume that a Frame in Traktor is 2.5 ms long.

Then, if two events were commanded respectively at t=0 and t=1ms, they will be interpreted as “simultaneous”, while if they were commanded at t=0 and t=3ms they will be interpreted as consecutive.

This can explain why a 2 ms interval returned a fuzzy result. Sometimes the 2 commands ended up in the same frame, and other times they ended up in different frames.

To confirm this theory and nail the exact length of a Traktorian-frame, could you be kind enough and do an experiment like the following?

100 single beat beatjumps consecutively with 1 ms intervals in between – and then count how many beats it skipped. Easy to count if you just set a given track’s BPM to 60 because a beat would be 1 second long.

According to the frame theory, Traktor would only jump 1 beat per frame.

Hence, if it jumped 40 beats, we’d know that there are 40 frames in 100 ms.

Therefore:

100 ms / 40 (number of frames) = 2.5 ms (length of frame)

What would I do with the theory? Not sure… But together with the Pseudo-simultaneity theory, we can come up with a general guideline for combining commands.

A safe way of going about combining multiple commands would be to add 3ms between all events (resulting in a fairly large overall execution time if you have a bunch of commands) but if the frame theory is confirmed, theoretically the following method should work generally.
Command everything that is doable now at t=0
Command everything that needs to wait until the previous command is done at t = 3ms

With this knowledge, my assumption is that, one could combine a massive number of commands with a total execution time of 3 or 6 ms.

The Inverted Direct

Pasting the video again, because I like it! And want it to be on the newest post! Ego!

Provisional Conclusion: Traktor handles things in Frame(*)-Simultaneity (*yet to be confirmed)

You can combine any number of controls in Traktor to one midi event as long as it is something Traktor can make sense of and execute “in that frame”. Anything else needs to wait until the next frame.

Thus, as handy as it may be, you cannot change an FX panel mode and set FX to ON with a single midi event. We need two midi events.

To get two midi events on one button, you can use the invert option.

Effectively, what the invert option does when applied to a button is to take action upon releasing. This, however, is a by-product of what the feature was designed for (at least not from scratch for-that-purpose). Essentially, all the “invert” option does is flip the midi values. (If you do not know this, try inverting a fader and see what happens). It just turns out that the button only has two values (0=off and 127=on) so when those numbers are flipped, you get a button that (to Traktor) sends an "ON’ message whenever it is released.

The standard Direct Button sets the value of things directly to the assignable value of your choice (e.g., effect 1 to delay).

It is not uncommon that one of the events we want in a combo is a direct event. However, Traktor does not offer the invert option for Direct events. I guess the software designers thought that the option to invert midi values was not needed here, and removed the check box from the GUI.

---- but they didn’t really remove the option! (HALLELUJAH!!)

So here it is, the Inverted Direct

Simply go into any interaction mode that allows you to check “invert”, and come back to direct mode. Now, the direct button takes effect when you release the button.

What can we do with it?

Escapemcp:
map the button to change deck flavor directly to Track.
map the same button to change deck size to invert-directly to Advanced.
You got your one push button!

VanGogo: Super FX Trigger (Sorry, no Hold yet)
map just the FX panel mode in direct.
map everything else in inverted-direct.
You got your super FX Trigger button!
(You need a separate FX off button or use a modifier to make the same button an on/off toggle after you’ve activated it)

Personally, I have noticed that many of my custom mappings worked only because I was already using Inverted-Direct without knowing it! Must have accidentally activated it while I was playing with the modes trying to find a behavior that meets my requirements. And now that I can knowingly make use of this option, I think that the possibilities are endless.

Lastly, there is one thing that worries me – the same reason I did not share this right away.

An inverted direct and a normal direct look exactly the same on the GUI (when the interaction mode pulldown is set to direct) - but the behaviors are different. To some, this is a classical example of A BUG.

Hence, I ask of Native Instruments:
Please do not fix this. If you must, then add a proper check box in direct mode - I can’t see any harm in it.