I must say that looks non default behaviour to me. If you bump into a slider it should should just affect the volume of one track, not all of them regardless of the arm status, at least that’s how it tends to work by default with my control xl mk2, both on waveform and bitwig. To be fair I never have more than 8 tracks in a project, so it’s an easy direct mapping, but even taking account the ability to select different groups of 8 tracks, that does not look default settings to me.
But even if it was just the one track, I still would not enjoy getting the mix ruined just because of hitting a fader or two by accident. I just don’t believe in the idea of physical faders that aren’t 1:1 mapped to the current parameter values, like motorized faders.
Mixing, to me, is something you do carefully bit by bit, where the majority of the time is spend doing other tasks like performing, trying things out etc. So the idea of dedicating these faders to that also feels off to me. They have the potential to be much more useful during more phases of the production.
I know that every person has a personal workflow. I think that the default behaviour is like that because a lot of people (including me) control the volume with the utility plugin. End of channel faders are blocked to 0 db so you can monitor the output, and they are very useful when performing or “live-mixing”.
2 Likes
Are you referring to Ableton? If so, you need to set the takeover mode in settings.
2 Likes
Yeah that caught me out when I first plugged my MK4 launchkey in…
This conversation and your use of the faders is compelling.
Traditionally, like most people, I’ve always accepted and used faders for volume. Mostly because it’s been dictated to me that’s the way it should be by the manufacturers.
But why?
Once I mix a track, I barely touch the faders again so why dedicate the most efficient physical control on the device to a task that eliminates their utility?
Interesting.
I never once even considered this until now but I’m definitely inspired to start mapping faders to other macros to see if I dig it.
Thanks. This is a pretty good forum indeed.
4 Likes
Traditionally the fader is to fade in and out an instrument, so quite a dynamic tool that is used frequently. Gain staging is different, done with a gain control/utility.
1 Like
No, Python is an interpreted language, there is no compilation going on anywhere. The switch from Python 2 to Python 3 happened in Live 11, not 12, that was what required migration of existing scripts because of breaking changes in the language itself.
But of course Ableton makes changes to their SDK with each version, and since that is not public for whatever fucked up reason we can only guess (or reverse-engineer) the differences between 11 and 12
Simple: faders give you more nuanced control of volume, and you can operate several faders simultaneously. That’s why most hardware mixers use faders for volume.
Even in a DAW, where all that can be automated you still see virtual faders for volume, and not knobs.
However in this discussion the context was controlling a Digitakt, not a DAW, and in that scenario also the knobs would send absolute values that don’t not match the volume set in the device.
1 Like
Thanks, yes, I did that. Still, it changes the mix if I touch then and that doesn’t feel right to me.
However…
This leads to new ideas to me. I already have a gain utility at the end of each track for automation because I like to separate that from mixing. I suppose I could keep yet another utility for the mixing part and leave all channel mixer levels at 0 dB and figure out if I enjoy using the faders for volume. It could in theory be a nice way to quickly mute some key elements if they are mapped to the buses (eg drums, bass, pads, arps, leads, etc). Maybe I’ll give that a try. 
But…
How do you lock them so they can’t go past 9 dB in Ableton? I think the max is at +6dB.
I’m glad I can inspire different ways of thinking. And now I’m curious to try to do it like everyone else does it. 
I didn’t mean I don’t get it in the traditional sense. In a dedicated, motorized mixer board, it makes perfect sense. But in a world where the physical location of these faders will almost guaranteed not be the same as the actual parameter values when you load a project in your DAW, it makes way less sense to me.
But as @JacopoAcquafresca and @Katmat are alluding to, if you ensure your project keeps those Ableton faders at 0 dB and do the mixing with Utility gain knobs instead, it becomes more compelling to me. Then you can simply pull up all faders to the max when loading a project and not worry about messing up the mix.
Indeed. However, DN2 x LC setup in the video has the DN2 mixer and physical knobs for fading volume in and out so that’s already covered. Freeing up the faders, with their visual reference of min/max values for other possible uses.
I haven’t tried it yet but just think it may be an interesting area to explore especially considering LC offers the custom pages so you can always retain quick access to the default behavior.
2 Likes
Cool thanks for the explanation 
1 Like
I map a Nanokontrol’s faders to the fx in Koala, but any other multi effect would work. They’re ideal for finessing multiple fx at once.
I also never use faders for volume. It’s too easy to screw up carefully controlled levels. If I played live it would probably be different.
2 Likes
Good question, it depends. If I am performing the possibilities are two: I don’t care, I simply use my ears or I put an utility with -6db before the fader.
1 Like
Mine turned up today, I can confirm that values are sent back to LCXL3 over USB, as long as LCXL3 is set up to receive MIDI in Ableton’s settings (second last line):
In the screenshot below I’ve got a bi-directional DJ filter with frequency mapped to Macro 1, which is then midi mapped to an encoder on LCXL3. Variation 1 has Macro 1 set to default value per screenshot. Turning the encoder changes the frequency, launching the Variation snaps the filter back, and the LCXL3 then picks up that the filter has returned to center, although the screen and LED won’t update until you turn the encoder again. This effectively allows you to use macros that are 0-127 and bi-directional, with parameter recall like Elektron.
Pair this with this m4l device which lets you midi map a single button to multiple variations, and you can set up one-button recall.
I really thought there would be more fiddling around to get this to work, but it just works!
3 Likes
That’s not ideal. Wonder if it can be changed with a firmware upgrade.
1 Like
Probably, and initially I thought so too but because it doesn’t have capacitive touch you have to turn the encoder for the screen to show the value anyway. So in reality it doesn’t matter too much. It may also be a limitation with Ableton, in that variations might change the parameters within Ableton but don’t send the new value as midi.
Either way, it’s fun as.
Obviously, it can never show all the incoming MIDI on the screen, that would be a mess 
I wonder if it could show the updates to the most recent / active controller of it stays on the screen for some time.
The real question is - why don’t the LEDs reflect all the incoming MIDI changes instantly? Why do we have to move the encoders to get the LEDs to update? That makes no sense and needs to get fixed yesterday.
1 Like
Both questions have the same answer, LEDs aren’t tied to midi messages like LCXL2, they’re handled internally now (likely because they’re RGB). So if the controller isn’t receiving the updated value from Live then it won’t update the LED or screen.
I turn the encoder and the screen updates as the values are sent back to the LCXL from Live, then when I trigger the variation the macro snaps to the default value but doesn’t send the value back to LCXL. The screen stays on the last value it received before the variation was triggered, but will update as soon as you turn the encoder. Same with the LED.
In practice it’s actually fine, because I know that the values that the variation recalls are all zero. So it doesn’t matter how bright the LED is, or what the screen says, and I’m using my ears anyway. Plus in a live set there’s so many other things to look at than the LCXL screen
1 Like
I am using the LCXL Mk3 with my Octatrack via USB and a USB host. Controlling the OT works from the LCXL, and when I update values on the OT the changes are reflected on the LCXL.
My problem is that the values do not sync at startup. So, for example, if I have an encoder set for FX1 param #2 which is mapped to filter cutoff, the OT project will boot to wherever it landed last, say 127, but the LCXL boots with a value of zero. That means when I turn the encoder, the filter jumps to closed.
I used the Mk2 previously, which had the same behavior but it was less of an issue due to fixed pots, vs. encoders. I find the Mk3 unusable in this state. Is that just how it is, or is there a way around it?