Match Ableton Clip Color to reflect as LED state on MIDI Pads for Akai APC40 MK2
A lot of use on the forum are asking for this feature. We want the Akai APC40 MK2 PADS to light up based on the clip color of the Ableton clip that gets loaded on that PAD.
why did you choose to only go with 3 states for LED feed back? what are you going to implement so that we have LED color matching to clip color on Ableton?
we bought and purchased CSS with the idea that MIDI Mapping would go by a lot faster with your tool you created, so far it’s been more of a hassle trying to get your program to work appropriately mainly because the APC40 has 3 modes like MCBeats has mentioned on multiple forum posts and responses.
MCBeats has even provided the solution to set the modes (giving us a template ready for you to update on your program so that it’s easier on the users to choose between modes (mode 0, 1, and 2).
Hello again,
Here’s a first updated version of the Clip Color Tracker:
- It uses Modifier m19 inside of your custom Session Box position changing Reactions to update the Clip Colors
- It now also updates Clip Colors when you add a new Clip inside the selected empty Clip Slot
I would suggest trying it out into a separate temporary script to see if it works at all with your device. I can’t test APC40 scripts so it’s easy for me to leave in mistakes. I’ve also added some APC40 tags in a few Reactions for my own benefit, so that I wouldn’t overwrite them accidentally (the new “disable” option in CSS3 is proving to be really helpful in this project for me).
There are still things I want to look at or change:
- I noticed, like 5 minutes ago in testing, that the current version doesn’t track Clip Colors well when a closed Group Track is thrown in between the Tracks inside the Session Box. I want to update the next version to ignore the Tracks within a Grouped Track whenever the Group is closed.
- I once came across a image of the 70 colors in Ableton (picture below) where a person had grouped them into sections. I’d like to make an update that, whenever a color_index is used for which there’s no direct counter part on the MIDI Controller, a color out of the same section is used. E.g. In Ableton you’re using pink but your MIDI Controller can’t show pink, then it will use red instead of the default color (default color is usually black and would then only be used as last resort).
- At the moment we’re using up 7 modifiers to track all the changes. I know a way to store changes inside a dictionary which can be stored inside a single modifier. I want to make a version of this project that would only need this one modifier. It would also create less clutter in the list of Mappings. I’ll do this after all the other updates, so that you can select which version you like best.

If you find any bugs or have any other insights or ideas, let me know.
Here’s the new version (both for APC40 MKII and the MIDI Fighter Twister).
Let me know how it works on your setup.
Here’s the latest version that reduces the amount of Modifiers being used + shrinks the amount of Mappings/Reactions down to 5.
It still uses 2 Modifiers (m19 and m20):
- m19 is used to trigger the update of the LED’s with whenever the Session Box is moved
- m20 contains a dictionary to save all the variables in that were previously saved in separate Modifiers
What you’ll need to do for it to work with your setup
All of the movement functions for the Session Box have been condensed inside 1 Reaction.
This Reaction takes 4 buttons as Listeners (the 4 directions of movement).
You’ll need to change these listeners in the following order:
1. Left
2. Right
3. Up
4. Down
Let me know how it works on your setup.
Hi Glenn
First, many thanks for your answer and actions !!!
1) So, regarding the new move direction condensed in one action, it works really well 🙂
2) Regarding the colored light. I conducted my research and I also observed that for it to work I had to add as a condition ‘listening to the buttons pressed’ as it did not react to traditional session box move. I see that you ended up with a similar (though more elegant) solution.
3) Regarding the mysterious orange lights: I have these orange lights that are sometimes displayed exactly where clips are, and for some reason also in column 6, regardless of if there are clips in column 6. They appear if I click anywhere outside the box with my mouse (for instance to change a parameter on a device, or on a clip slot outside the session box). Concretely they will replace the right colors and every clip becomes orange (+ some lights appear on column 6 regardless of if there are clips there). Moving the box or reactivating manually the script for clip colors remove the orange light (ie. the pad takes again the appropriate colors and column 6 lights disappear).
For a long time I thought it was part of your script not working correctly. But after rechecking, in fact these orange lights seem to be a behavior that is part of the APC40 MK2: they appear even if there is no script about colors. I have no clue why they are here. Apparently when the script you provide is activated, it overrides them and then everything is fine and the clip color matches. But when clicking outside the box, the device seems to revert back to some kind of default behavior and these orange lights appear. I’m trying to find a solution to remove the lights from the APC40 by communicating directly with it through Sysex but I don’t have much hope on this front.
=> I think maybe one solution could be to constantly reactivate the color script for nearly any action taken in Ableton Live. Maybe through a listener that is quite general (is there something like “when anything is selected”?) and that would reactivates the color clip script each time…
Cheers
Almost sounds like you need a Listener that triggers whenever you click your mouse in Ableton.
I’m guessing this next suggestion won’t fix all of it but you could try taking away the 4 conditions in Action Block 2 of the Reaction “Save Scene and Visible Track Positions” which makes the script only update whenever you click a clip inside the Session Box. Those conditions were mainly to limit what I deemed unnecessary computing but in your case it might help out.
Maybe I could try and make a Reaction that continuously updates the LED’s, like with the code you got through ChatGPT by re-scheduling it. I’m wondering how intensive that would be on the program, but there’s little harm in trying it out I guess.
There’s also a lot that hasn’t been considered yet with this script, like how to make it show on the LED that a clip is playing. I’m guessing you’d want it to blink. And maybe also a way to temporarily turn off this feature if you want your LED’s to represent something else.
Hi Glenn,
-To simulate a nearly continous triggering, I’m using clip_playing_position (it was the most simple method for now because I’m not comfortable with custom code), it work 90% of the time (for some reasons sometimes it does not refresh even if a clip is playing). I guess for now I consider this workaround functional
-Yes, indeed the clip playing part is very important because it helps a lot to quickly see where am I on the session box, especially as it is normally blinking. I can’t use the remotify session default function because :
1) It dose not enable blink (which is done through channel on APC)
2) Default behaivor of session box is now quickly ovverriden by the custom reaction color script.
Can you please point me on how to implement this? So that the current clips playing are blinking. Normally blink is a midi message to another channel (for instance channel 16 instea of channel 1) I have no clue if we can do that – worse case a continuous on/off would do. To me the complex part I have no clue is to detect the clip playing and have it a specific behavior that overrides the normal reaction.
I’ll check it out in the following days. I was working on something else first.
Hey Neoseed,
Here’s the latest version of the script.
The Reaction “Set Button Colors to Clip Colors (APC40 MK2)” is now only fired when the script is initialised. The function inside that updates the LEDs will continuously be rescheduled. I hope this will solve your problem with the LEDs turning orange.
To give you the ability to limit this functionality to certain modes, I added a way to assign which modes you want to use it on. Info can be found inside the Reaction.
I also implemented a blinking pattern when a clip is playing. All blinking buttons should follow the same pattern, so it looks uniform.
Let me know how it goes.
Hi Glenn,
First many thanks for your help as always it’s extremely useful !
-Your solution does work vvery well, both regarding the continuous refresh and the blinking of the selected clip.
-In the meantime, I made some progress of identifying the source of the orange lights and have partly ‘solve’ it (but your script is still useful as you will see !). The orange lights come from the CSS parameters when creating the session box in the area “Clip state LED feedback”; if I let the parameter on “None” (why orange I have no clue; my guess is that 127 on this device is dark orange and maybe it automatically put 127?).
Basically the orange light where were any clip slots were present ; as for the mysterious orange light where no clip were present on another column, it was on areas where a track was armed and thus a clip could be recorded (so corresponding to something in the Clip state LED Feedback section I guess).
Anyway, I can now make all orange light disappear by selecting the value “0” (which correspond to turn off LED) instead of “None” for all parameters in “Clip state LED feedback”.That being said, while I remove the orange light, then I have a variation of the same issue as before: any click outside the box or on any parameter will make all clip disappear (as orange is now equal to turn off).
But now I am wondering: isn’t it a bug of CSS? because basically, it’s as if clicking outside triggered some kind of behavior relating to the “Clip state LED feedback” section. Your script is a workaround as it continuously refreshes and override it but I wonder if it’s maybe possible to remove this behavior in the first place now we know its source – as if clicking anywhere send the instruction “refresh Clip state LED feedback” but if you put ‘None’ you still get something (orange light which I think is 127) ; and turning off using 0 is not like doing nothing (as clicking will make all clips disappear etc). If it’s the case, a solution would be to extinguish this unwanted behavior in the first place – this would also cost much less resources as no continuous update would be needed
As for your script I have a question: is there a resource where I can have some pointers about what the codes are for clip status (clip being deactivated, clip playing next…) ? So I can later add customization building on the work you already did. Basically reconstructing a functioning clip state led feedback area…!
Anyway again thank you for your help I think we now have at least roughly enough for a functioning template.
Cheers
On my AKAI MIDIMIX, which does not support RGB, the buttons light up orange with value 127, so it might be the standard color for AKAI products. I once found an RGB chart for the APC40 MK2 and 127 is a dark brown. https://forum.bome.com/t/new-akai-pro-apc-mini-mk2-initial-led-mapping-summary/4752/13 Scroll down to post 13 from username “joemfry”.
If you want to see all the possible colors on a pad, you could make a Reaction (in a throwaway script) that listens to a knob being turned and that sends the value of that knob to a pad (+ maybe also logs the value in CSS so you can read which value corresponds to that color).
Have you tried out my Reactions on a separate, otherwise empty, script? If there’s still interference from the the orange color then we’ll know for certain it’s not caused by anything else in your script.
-I’m 100 sure the orange light have nothing to do with your script. I have script where they appear and your script is not present.
-I’m 99% sure it’s the Session Box mapping created by CSS, as I can change their color to other stuff by changing parameters in the “Clip state LED feedback” by replacing None by other colors
-I’m 99% sure the orange I observe is indeed 127. It’s “dark orange” according to the table here : https://forums.pangolin.com/threads/apc40-mkii-lowering-button-brightness-beyond.29169/ (which I found more faithful than the other coloured table)I sent the 127 code using BOME and it looked the same (unfortunately I can’t have both Ableton and BOME at the same time, so I never had both color side by side, its possible but requires too much configuration for a quick test).
I’ll ask in another post if it’s a CSS bug !
Sign up
User registration is currently not allowed.
Small update:
It’s looking good. On my own device (MIDI Fighter Twister) I got the colors to work like I mentioned above. The tracks are now being handled correctly, grouped tracks aren’t a problem anymore. Moving tracks around will now also update the LED’s.
I think I’ll get an APC40 version out somewhere in the next 24 hours. It still might be useful to try out the previous build by then, you might find bugs that I could remove before the next build.
Then I’ll still try to make a version that uses less Modifiers.