S4 - Traktor Pro 2 - Effect Jogs Extreme [Update Version 4.1]

I am going to add the restriction for users of my mapping to not change to midi mode. If they want to go to midi mode, then the mapping is going to be useless. (who switches to midi mode while performing anyway?) I also will also add the restrictin of not using the load button when changing the deck controls to C/D, at least for now.

I've covered browse mode, I believe

layout changes don't affect the load button function

But surely I wish NI would come up with a better way to map (smarter Controller Manager) and also more freedom to remap the S4.

Load (to change the mode to FX Jog and back to scratch mode)
Shift + Load (to load a track in the deck)
Browse + Load (to load a track in the deck)
Browse + Shift + Load (to load a track in the deck)
Jog press + load (can't remember the function, but it is covered)
Deck C (or D) + Load (I believe, load a sample in the next open slot)

My mapping will get there, sooner or later.

I was playing some more with my mapping. I deleted the default S4 mapping and imported the default mapping stored in the settings folder of the software. This is a mapping where you can actually edit the commands, however you loose the loop size indication and also the ability to skip through the song with the left loop knob. Since this is something I don't want to miss, I deleted everything and reloaded version 4.1 and low and behold, I found something missing, which I had thought I had built into this version. That is, I thought you could press shift + load to load a song, while in the FX Jog mode. Well, that was screwing up the modifiers and I was like WTF?

I could have sworn I had covered that.

At any rate, don't press Shift + Load with 4.1. It will screw everything up.

Another issue I found is changing the deck controls to deck C or D. If you press the load button while deck C or D are on, then that will also kill the modifiers. I will fix that in the next version.

If you want to still use the native mapping and want to add stuff on that, there are two ways:
* either you negate or set up something in opposition to a native function (like adding a function with shift on the cue buttons, so you create antoher toggle when cue is used with shift)
* you want to add stuff to something that already exists. Depending on which controls you want to do that, here is where the harder part arrives.

That's the second point we are interested in this case as we want to use the native option for the jogwheel to control other FX(s) than the third slot or parameter.

But first before jumping into that, there are some rules to be followed: you want to produce a system that will be consistent and that cant' be disrupted. In other words if you set up any kind of modifier system it must be 'true' all the time, otherwise you're going to mess with some critical controls. In the case of the S4, you have to duplicate the behaviour from both the hardware and software and cover all that can happen.


A simple example in our case:
we use the load button for fx activation so you need a toggling modifier to represent that (from 0 to 1 and back). One modifier condition taken.
But you can still use shift + load button. That's a second modifier condition.
But there's the browse mode, because the load button still loads when in browse mode. You need to create another modifier so when in browse mode your first modifier will not touched. That's already a third modifier condition.

Other things have to be taken into account like the layer we're working with. If you switch from deck B to deck D for example, the load button/fx activation is disengaged so you have to create that for your first modifier. Likewise if you switch deck and if your deck D is a sample deck, the load button doesn't work for fx activation, so that's something you also need to preview. And if you revert back to deck B that's also something that's need to be represented, etc, etc, etc
So one of the first issue to overcome is being obliged to create all those events/modifiers, that's already several of them, within your first modifier when you have only two modifier conditions available. Even if it's a bit complex, not a big deal, there are ways to use multiple layers of modifiers inside a modifier. Of course some of those modifiers have themselves an influence upon others so also something you want to recreate right?
If you don't do that you can't trust your load button.
It's not finished...

But if you created the browse mode, you also have to duplicate the copy mode as they are using the same button but in different ways, one is a toggling modifier, the other being an hold type but with a potential sequence of a lot of different things to be pushed (holding browse button , then using a sample play button or cue button would make you enter the copy mode, but then you can stop there so it reverts back to normal...
Just this one is funky to recreate....

Ok, let's say we are quite good at solving all the above and we set up something that works. That was only the first part.
The second part is the jogwheel itself and it's own behaviour. It doesn't react the same if you're using shift, if the load button is engaged or not, if you're in browse mode, if you use a sample deck (as there's a modifier system to be set up here as you can use the jogwheel to pitch bend one or more samples), so that means, the deck layer(s), the layout, etc, etc...
That's not finished.

Both the two parts above need to be interacting with each other.





Do you see the pattern? In itself it's complex, even with some mapping skills, whatever in the end, the controller manager allowing you only two modifier conditions will stop you at a point. Even by using some advanced mapping technique.
The native mode is using an integrated coded system you just can't reproduce fully.


So a simple example in your file. You just didn't replicate the browse mode or the copy mode. So as soon as you touch this specific button the modifier you set up is wrong and next time you touch the jogwheel and/or the load button, you're going to mess with something big time. Your system just don't work, it's not a personal thing of mine to say that. It's not even working for one deck, not doing it for at least two decks shows you didn't grasp the whole problematic. Can I say that without someone telling me I'm mean or harsh? Ok , ok , I'm provoking on purpose here ^^

Now to reduce the overall complexity of all this, one can decide to say that a system can only work for a specific layout (so you don't have to cover some issues), or that you'll never change from a layer to another, or never switch to midi mode, or... So you put restrictions in places which is ok (to an extend) but even like that you'll have great difficulty to cope with some obstacles.
In all cases you need to have a reliable system, I cant' stress that enough.

You create modifiers and then you realize you need other modifiers, and others linked to that, and others, and others, and also that all those different modifiers have interactions between themselves.
Do you get a bit better now?

So unless proven wrong, for the current knowledge - and the tools - at our disposal at the time being, it's not doable to produce a system that will be true, working and reliable 100% of the time, to be used in conjunction with the native mapping.