Does setColor() on a control work? It was not in version 20. SetName() is fine. Haven’t tried other things.
seems to work fine:
local control = controls.get(1)
control:setColor(0xff0000)
-- or
control:setColor(ORANGE)
1 Like
weird. Here’s my LUA script that doesn’t change the color of the button that is pressed.
The log shows the correct text being printed, just no color change for the control.
It’s assigned to a function that is called from a Note control, momentary, in position 1, note number 38
recording = 0
function recToggle(ValueObject, Value)
local message = ValueObject:getMessage()
local keyVel = message:getValue ()
local control = controls.get(1)
if (keyVel == 127) then
print(string.format("Recording flag: %d", recording))
if (recording == 0) then
control:setColor(RED)
print(string.format("color set to RED"))
else
control:setColor(WHITE)
print(string.format("color set to WHITE"))
end
recording = math.abs(recording - 1)
end
end
Are you sure the control you want to change is indeed control 1?
To be sure shouldn’t you resolve the correct control number from the valueObject?
How do you do that? I though the control number was an absolute based on position on a page and page number.
The valueObject:getId() returns a string with the word “value” assigned to it.
example:
local control = valueObject:getControl ()
if value == 32 then control:setColor(RED)
I’ll try that, thanks.
BTW - where is that documented? I scanned through Controls, Control, Value, etc and didn’t see it.
EDIT - tried it, same result. Dumped the EPR file, ID for the control is 1.
I can toggle visibility and name (BTW - name can be displayed in mixed case using setName()), but not color.
No idea where I got it from, honestly. Not entirely sure about it either, since the setColor commands weren’t reliable in most cases. But I’m not in the habit of guessing the commands, so I must have picked it up somewhere…
The recent notes implied that the latest beta can receive sysex dumps larger than 256 bytes. I’ve been trying to receive a 668 byte dump and it seems to be locking up the ElectraOne and the web editor and all of Chrome.
Basic onResponse() functionality:
function patch.onResponse (device, responseId, sysexBlock)
local blockLen = sysexBlock:getLength ()
local deSyx = {}
local skipBytes = 4
print (string.format("Received sysex, length = %d", blockLen))
sysexBlock:seek(skipBytes)
for i = 0, (blockLen - skipBytes) do
deSyx[i] = sysexBlock:read()
end
print(string.format("Patch #: %d", deSyx[0]))
end
I just noticed that if I entered “Text Overlays” for a “Fader”, then the entered Text appears only for the entered values, the intermediate values are not shown by E1. so far intermediate values were also visible. will it stay as it is now?
1 Like
Good news: on testing my Summit preset, which wasn’t working fine due to a mistake in the MIDI setup of the Summit, and for which the issue could not be solved in FW2.2 due to lack of memory, I now can resolve that issue via workarounds in lua in the preset itself on FW3. That is good news. 
More testing though is needed to have a full view on the FW3 preset version.Electra One App
Some other observations of a cosmetical nature:
- Please add the original 6 colors as preset colors.
- The standard pallate of colors could do with one less green and one more blue. I’d love to see some shades of grey as well
- In case of a fader with text overlay, the bitmap of such overlay isn’t shown.
- The variant on lists, called ‘Value Only’, is brilliant to work with. But it does change the standard left-to-right behaviour of the control into a round-robin behaviour, which is not always an improvement. It would be great if we could also choose that behaviour as well (a third variant perhaps ?)
- Is there a way for a ‘Value Only’ list variant to increase the size of the bitmap within the rectangle?
- This ‘Value Only’ list variant makes a selection behave as a button. Once again it would be an advantage if we could press a button, without the focus on upper, middle or lower section changing.
1 Like
I’m away from my music stuff, but couldn’t you add additional logic to the LUA scripting to keep track of which section is current and then compare it against the control and switch it back? That might happen fast enough to be usable.
I didn’t explain it cleanly, but hopefully you get what I’m trying to suggest.
2 Likes
Martin,
setColor() works fine on a fader control, but not on a list control. Better said, the new color is only applied after you swap to another page and then swap back.
That should be fairly easy to do. I will add that.
I think this is the same issue as @oldgearguy reported earlier. It looks like that the internal repaint function is not triggered. I will review that. Thanks!
1 Like
Interesting. I was kind of suggesting the template developers could do this rather than have it part of the E1 OS (again - very scattered the past couple days - not sure if I read too much into your reply).
But - if this was going in the OS, it would be useful to have a flag that could be set to change focus or keep focus when non-highlighted objects were touched/moved.
The devil is in the details - I’m sure sometimes you’d want the focus to change, other times not, but how does one change that dynamically (probably per-page) unless you embed a check/change condition in a LUA script and have the object call that?
1 Like
Another one @martin
A hidden control still remains active. Tweaking the encoder, data is transmitted. That is not expected
2 Likes
v3.0-a.22 is available for download on the beta. amongst others it brings:
- pads do use white colour labels only (for better visibility)
- hidden controls are disconnected from the pots
- colours of all types of controls are updated immediately after the Lua control:setColor() function is called
- MIDI learn handles intensive MIDI traffic better (there were issues with Prophet X)
- Faders with overlay bitmaps are displayed correctly
Firmware file:
firmware-3.0-a.22.img.zip (317.1 KB)
3 Likes
The great thing with the additiion of grey colours is that now, based on context, one can grey out a control instead of hiding it. It is a good way to indicate a certain control exists, can be tweaked, but will do nothing for the current settings.
Another use example is space saving. For instance I was just missing one space on a page for a pad to change between regular LFO rate and Sync’d LFO rate (they both had there own overlay texts and were on a different CC). Solution: when tweaking the greyed one, it automatically sends out the command to change the rate types, changes its own colour to green and greys out the other one.
4 Likes
Hello !
I saw this " * hidden controls are disconnected from the pots" From the last firmware betta update…And it makes possible for me to achieve something i wanted to do with the E1.
Does the Firmware 3.0 a22 is stable enough compared to the 2.2 or should i wait a little more ? Thanks ?! Have a nice Halloween day !
1 Like
Hi @Abbes, it is fairly stable but there are still things to tweak / fix and the release of that firmware with come with an updated version of the web app. Only users who want to help with testing and who are willing to take risk of possible issues should use beta.
I do expect 3.0 become production release some time in November.
2 Likes