Pads led turns off by itself

Hello! I wonder the same thing, I just checked quickly and noticed you are using reactions to turn on the LEDs and at least for me that's when I get this problem.

Repro: Create a completely fresh script, using only two reactions that simply turns on a LED each on initialization, they turn on as they should but as soon as I click somewhere in Live (select a device, track, row or whatever) they both turns off.

Also only with LED's that uses Note On to turn on, I haver other LEDs using CC's and they don't do that so something sends a bunch of notes off somewhere I guess?

I tried the video tutorial for LEDs using reactions, where you set LED color depending on if the song is playing or not, and I noticed that then I don't get the same behavior, that just works.

I'd really like a little guidance here, it feels to me as this might be connected to how listeners actually work, or is it simply a bug?

I have similar problems with the LED's on my session box.
As soon as I select a device, the session box disappears (all LED's of the grid on my midi device go out). Turning the 'Highlight Navigation' encoder usually turns the lights back on.
In its simplest form, it is not even using a Reaction, only a 'Session Box' and a 'Highlight Navigation'. :(
Hopefully, there is or will be a fix.

Same issue it seems, as soon as I added a listener it broke my LED feedback, even after deleting the reaction it doesnt work.

Yes, it seems like a similar issue, I am confident it will be fixed in one of the future updates.

How does the log files work with all of this? I am not able to find the Ableton log on my Mac. All updated etc. Just not in the library path you guys specified.

It could be that the directory where your log file resides is hidden.
If I am not mistaken, the file you are looking for should be --> /Users/[username]/Library/Preferences/Ableton/Live x.x.x/Log.txt
On the Ableton site there is an explanation on how to find it; https://help.ableton.com/hc/en-us/articles/209070509
Hopefully, that helps.

Hi,

I am looking, see the folder structure but do not see the log.txt file anywhere..

What I am asking is what effect does not having the log file have on CSS?

Kind regards,
Luke

Hi Luke,

Strange, you can't see the log.txt file..
I made a screenshot of my CSS settings just to make sure.

The log is read in CSS to check if and what the errors in your script are, see screenshot.
When you click the log symbol (exclamation mark) you should be able to see any errors.

So if you don't have a log.txt, you will have difficulties troubleshooting your scripts.

Hi,

I seem to have an issue, I followed the instructions on the setup of CSS, but cannot seem to read the ableton live version.

Is there something that is missing?

My mapping works fine, but the lights turn off as I press the button (after I tried to use reactions) but then moving the session box makes everything work as intended again.

I have attached a screenshot, am on the latest version of ableton and macos.

Please assist.

Thanks,
Luke

Hi,

I would also like to note that the LED feedback works fine on downpress, but when I release the button it goes off.

Is there anything you can think of that would affect my LED feedback in this regard?

Please assist, I am not able to use the software like this and will probably just request a refund if not able to get this right.

Sorry, I know it is some stupid error on my end most likely but support is required.

Thanks
Luke

Hi,

It seems to definitely be an issue with the momentary/toggle options, When I choose toggle, it works fine, when I choose momentary, it clears the LED information as I release the button.

I have tried deleting the mapping, and doing it again, same result.

Please advise.

Kind regards,
Luke

I have made a reaction where the device state of track 1 device 1 parameter 0 (device on/off) enables a midi value of 122 or 120 on my controller (red or green depending on state of device).

The script seems to work fine on downpress (correct colour) but when I release the pad the LED turns off. same issue as when I use the old LED feedback option.

I don't see how "im sure this will be fixed in a future update" is an appropriate response as it essentially makes my mapping unusable in live situations. I have some shows coming up and cannot do it blind.

Please can someone assist? John? 303?

Thanks guys, hope we can get this working ASAP.

Cheers,
Luke

Hello LukeTaylor,

I assume/hope the "log.txt" issue is solved?

Did you manage to set the "version" option in settings? You probably already saw the video on setting this up, to be sure, here is a "shortcut" link, starting at setting the locations: https://youtu.be/MlJk4Qj9Y9U?t=78
Even though your version is not set, your settings page does not give any errors, so that is some good news.

I will have a look at your script and let you know if I can help out.
Till soon!

Hi Luke,

I installed your script, adapted it to a controller I own, and as it is, it works flawlessly for me.

In your last post, you mention: "the device state of track 1 device 1 parameter 0 (device on/off) enables a midi value of 122 or 120". I guess you mean the "Hi Kill" - "On/Off 8" button in your script? I don't see another dedicated Reaction for this in your script. This also works great here.

Switch types "Momentary" & "Toggle" work as they should for me, although I always set the "Control Override" on "Default" unless I have a specific reason to change it.
So for instance, on your "Hi Kill" button;
- Momentary: the button is activated (white led) --> push once deactivates and turns yellow --> push once more and the button is activated again giving the white led again
- Toggle: "Hi Kill" is by default deactivated and is yellow --> push and do not release activates the "Hi Kill" (turns white) --> release and the button is deactivated (yellow) again

So then I checked your Controller script and saw that the "MIDI Message Settings" were the same on all of the pads and some buttons and knobs as well.

I think your problems could be solved once all the midi inputs on your controller script are set up with their respective midi type, channel and value. Here is a link to a video that starts at the critical moment for assigning the inputs: https://youtu.be/VOddX46Vtaw?t=370

Hope this solves some of your issues!

Greetings!

Thank you so much, I will check this out!

Hi,

I am seeing the pads defined uniquely in my controller mapping. I messed around a bit and the issue seemed to fix itself. I removed the reactions from the mapping because they do not fetch data only react to changes, but the mapping was giving me LED feedback as I wanted.

It worked for about 20 minutes, and then after my 5th or so reboot of ableton the issue came back, pads turn off as soon as I release the pad (I changed nothing on this mapping as I started on something else.

Must be a bug, I dont know.

I also set up my track selector buttons, and they seem to move the encoders but do not move the view in Ableton. Do you know if I am doing this correctly? I want to be able to see the effects chain in each channel as I select on the controller,. The LEDs give feedback when I change it with the mouse.

And to answer your previous question, no, I have not solved the log.txt issue yet.

Please help meee!! It doesn't look like there is anything wrong with my mapping, is this a known bug? Im going mad over here!

Thanks!
Luke

Hello Luke,
It is indeed strange behavior that the LEDs do work and then don't. I also can't understand why there is no log.txt file. That is a file that Ableton renders automatically. It is needed for troubleshooting. Do you know if you have a script like options.txt that prevents it from running? (https://help.ableton.com/hc/en-us/articles/209772865-Options-txt-file)

Some good news then; in order to get the track selector buttons working, you only have to change the 'Control Override' to 'Absolute'. Like in the screenshot hereunder.

I'm having a similar problem (I think)...
I have a button on my keyboard that I'd like to keep lit in blue (mainly because it looks nicer than when it's red!), but to allow me to turn a device on and off (an octave shifter in the first slot).
My script is doing what I want it to do, except that when it initialises, it changes the button colour to red.
I'm using a reaction to respond to the button being pressed (whatever value is sent), and one of the response actions is to send a 127 back to the button, so it turns blue and stays blue on subsequent presses.
But if I add another device, or switch tracks, it goes red again!
I've tried making it a momentary and a toggle button, and even a "knob" with a range of 127-127, but nothing seems to stop the script from resetting it to red (0) on initialisation, device selection and track selection (at least I think those are the events that are responsible).

Actually, going the wrong colour on initialisation was easy to fix with another reaction that forces the value to 127, but it looks like it would need similar reactions on device and track selection to fix those too, which is a lot of fixes for something that doesn't feel like it ought to be happening in the first place.

Maybe what's needed is the option per control to exclude it from the global feedback behaviour?

Hi aventham77,
This is in fact already possible :-)
There are 3 places in CSS where you can define LED feedback depending on the specific situation.

1. Global Controller: the controller's default LED settings in the "Controller Templates"
2. Global Script: the script's global LED settings
3. Specific Script: the individual mapping's LED feedback

A comprehensive tutorial on this can be found at https://youtu.be/ssT2qUHsFa4

Thanks 303_
- I know you can customise the default LED feedback that occurs when you use a given control, and I've done so (I've disabled it, so I can control it from a reaction instead), but there are other LED feedback "behaviours" firing when my script initialises, and when I change the selected device or track, which are having an unwanted effect on the particular control I'm trying to configure. Ideally I'd like to be able to disable/override these just by configuring the control itself, but which I've so far have only managed to do so by adding a script initialisation reaction, and customising the LED feedback settings on all my track selectors and device selectors.

Hello aventham77,
Thank you for the correction, I think I see now, well partially.. ;-)
Let me break it down so I am able to better understand your question, bear with me:

• You have 'Reactions' which fire LED feedback. (That's why my last post was not of any help to you;-)
• When you select a track or device, LED feedback breaks. May I ask what exactly happens, they disappear or change to another color?
• Also when your script initializes, you get unwanted LED feedback. I don't understand that part exactly, since initialization is only done once when opening an Ableton Live Set. This would mean that the LED feedback you scripted is not working correctly from the start? If so, when is the moment when the script does display the LED feedback correctly?
• "I'd like to be able to disable/override these just by configuring the control itself" That is not clear to me. What do you mean by 'these'? Where do you like that functionality? Because like you said, you can override LED feedback by using a 'Reaction' (or in other use cases by the 3 methods described in my last post).

For what it might be worth to you or other users; in my case LED feedback breaks when selecting other devices. A workaround that solved that issue for me was; whenever I select a device, it goes to its own Mode where the specific device can be altered, LED feedback returns to normal then. For me, this works flawlessly, but I can imagine that workflow might not suit other people.
So in short, changing 'Modes' seems to restore the LED feedback, at least for me.

Hi,

It seems like this is a common issue, and makes using this in a live environment unsuitable, which is why I purchased this software.

Please advise on how to refund my purchase, I believe I am within the 30 day window.

Kind regards,
Luke

Hi Luke,
I understand your position, I will contact you about the refund!

I do want to let everybody know that the LED issue is being investigated and is going to be solved.

I know that for now, it is not a solution, but since it is lifetime software, it will be fixed at no extra cost and a lot more will be added in the future.
I hope we will see you again once the bug is solved! ;-)

Meanwhile, I wish you happy producing and performing!

Hi Wim,

I have a button on my keyboard, which is designed to enable or disable an "output zone" (locally in the keyboard), but which also sends a midi cc (127 or 0 value) when toggled. I don't need the local zone behaviour, so am repurposing this button to do something more useful in Ableton.
My reaction responds to any press of this button, and returns a 127 to it, to keep it in its "enabled" state. Indeed, ideally, the button would only be registered with my script as something that can send/receive a 127 value - I'd rather the script wasn't "aware" that it can send/receive a 0 at all.
But despite my best efforts to avoid it, my script keeps sending 0 values back to the button (setting it to red/disabled) - when the script is initialised, and when I select modes, tracks or devices. So, for now, as a workaround I've had to customise led feedback in several places to override the unwanted behaviour.
It seems to me that the sending of these 0 values must be part of a general "control-resetting" routine, and if so, what would be ideal would be to have the option on each control as to whether or not it should be included in that routine.

It seems to me as if the way the essential CSS logic works at the moment is that every control is treated as "stateful" - per mode, track and device (at least, in my script with two defined modes that each have their own track and device selectors).
So whenever I select a different mode, track or device, the "state" of my control is reset/recalled; whereas what I"d prefer is for this particular control either to be treated as "stateless" (so mode/track/device selections do not have any effect on its value), or for its "default state" to be registered as 127, rather than 0.

Hello aventham77,

Yes, I have come across that issue myself.
I will add it to the 'discussion list' of things to come. I will keep you posted about that!

What I did was use a 'Condition' in a 'Reaction' so the button only triggers when it is not 0. (in the example it is set to trigger when it is higher than 1, that also works..)

Could that also work in your case?

Many thanks Wim,

I kind of have the opposite problem to that - my button isn't triggering anything when it shouldn't be, it's just being sent 0 "feedback" values (by behaviours that are being triggered elsewhere) that I don't want it to be sent. But I'll check whether adding such a condition helps unharness it from those other behaviours.

I wonder if it would be possible to implement some kind of "global mode" for these sorts of controls, whereby, whatever mode the other controls are in, the "global" controls are always available, without their state being affected by mode switching or anything else that happens within the selected mode. That would seem to me to be a hopefully relatively simple way of avoiding this problem altogether.

Sorry for the spammy amount of posts in a row, but I've just found a much better workaround to my problem - I'm almost tempted to call it a solution! It occurred to me when I remembered that I'd always thought mode selectors ought ideally to be implemented as the sort of "global" control I'd suggested above.
It turns out all I needed to do to stop my button receiving unwanted LED feedback was to register it as a "mode selector" in each mode, of that same mode. This has stopped the script from trying to send it 0 values on track or device selections, and if it's still sending it anything on mode selections, it's a 127 to indicate that the mode is selected. Nice!
I'm not sure how much help this approach might be to someone who does actually want to make script-defined changes to the status of their button LED (it suits me fine as I'm happy for mine to stay on), but it might be a partial solution - perhaps you can handle the rest via reactions and modifiers?

Hi aventham77,
Indeed a great way to solve the problem! :-)
I will keep you posted about that feature.
Kind regards

Great news everybody!

There has been an update on the server-side which could be the end of the LED breaking issue..
Just install your script again from CSS to try it out.

In my case, it solved the problem, my LED feedback stays on :-)
If it doesn't solve the issue for you, then please let us know here in the forum or via mail. Give us some info, when does it break, is there a way to get the LEDs back, are there errors in the log, ...

Waiting for your feedback, my fingers are crossed ;-)

Thanks Wim,

That sounds like great news, but I'm not sure exactly what it means... I thought CSS only connected to a server to authenticate logins?

I guess the conversion to Python must happen "in the cloud" then - good to know! I suppose it avoids having to faff around with different client libraries, envs etc.

Hi Wim,

I may well be misunderstanding what I need to do in order to benefit from this server-side change, but I've tried removing my mode selector fix, and re-installed my script, and my button is still getting those pesky 0 feedback values sent to it when the script initialises and when I switch modes.

Ah - I've found the changelog now, and it sounds as if the new fix is a bit too specific to solve my problem:
"Bug with Session Box LEDs turning off when the selected device changes"
https://remotify.io/product/control-surface-studio/changelog

Hi aventham77,
Yes, what I meant with the server-side update is that it is not necessary to download a new setup file, I will explain that a bit better next time ;-)
Since the start of the thread, the question has shifted a bit.. The fix was indeed targeted at the question of the original poster.
But you have figured this out already by viewing the changelog :-)
I don't have any updates yet for your specific problem. I will keep you up to date!

Thanks Wim, and sorry to the OP et al for ending up rather hijacking the thread - I thought I was experiencing the same problem, and I suppose it is essentially the same kind of problem, just with a different kind of control and use case I guess; fingers crossed, if the same "pattern of behaviour" lies behind both, the specific fix for one can be generalised to cover the other.