Release running during initialisation

Grid
1

First, hi all. New user here. Please be kind to me. :slight_smile:

I just got a VSN1 and am completely new to the Grid system. I’m having quite a hard time with the documentation or lack thereof but it’s a good beginning for something bigger and better I guess. :slight_smile:

Anyway. During my slightly frustrating excursions among the different elements and their events I discovered that the Press/Release action blocks is not working as I understand it should from the documentation.

I’ve put a Press/Release action on my Button and added a print() in the Release trigger section. What happens is that during initialisation (booting/changing page) in line with the following table

System Setup
System other Events
Element 0 Setup
Element 0 other Events
Element 1 Setup
Element 1 other Events
…

the print gets executed. In my view this shouldn’t happen since it should be about events coming from interacting with the hardware like “Press button” and “Release button”.

I’m now going to change it into a code block instead but I just want to ask if this is a bug or intentional? If it’s intentional the documentation should probably be a bit more explicit about it. :slight_smile:

2

It does get executed because you put it into the Release section.

The Release section is pretty dumb, it only checks if the button is in a 0 state or not.
When Initializing the module, all buttons are in a 0 state, unless their Setup changes that. Because of this when all Other Events run, the Release section will run too.

3

Yeah, ok. Thanks for the reply.

That’s the thing, it’s two verbs, “Press” and “Release” indicates that it’s triggered when something is happening now. It’s misleading as it is. Calling it “Pressed state” and “Released state” would be more clear for what it does.

Also, I’m quite confused to the reason why the initialization order is mixing in the other event action chains for each element. It would be logical if only the “Setup” action chains where run right after boot to get the unit into a predetermined state. Then only the “Other” action chains when an event is happening. Maybe you can explain to why this decision has been taken to run all the action chains during boot.

Also, on the VSN1, I can’t get the “led_color” and “led_value” functions to work when calling them from a button code action, whilst addressing the other button LEDs. When pressing a button, I’m trying to reset the other button’s LEDs. The only LED that I can get to work is the endless jog wheels LEDs.

Is this a known bug or am I missing something?

Thankful for any reply. :slight_smile:

4

Ok. So I discovered that to addressing the leds from the System.Setup chain I needed to use the following format:

element[n]:led_color(-1, {{255, 0, 0, 1}})

But now I have a problem addressing the endless pot LEDs… hm… I’ll continue investigating.

5

Yeah, I just noticed yesterday that the reference part of the Simple color functions are wrong on the Docs. I’ll update that today.

You’ll need a table of tables for the colors so:

self:led_color(led_layer,
{
{r,g,b,a}, -- color1
{r,g,b,a}, -- color2
{r,g,b,a} -- color3
})