here’s some explanation:
[quote]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.[/quote]
As the mapping gets bigger and better, I’ll have all command commented.
Keep your good work in your spare time!