time to switch between 2 state

hello i use this code :
[(press){state:1}{@shift:1}{text:"hello"}]
[(press){state:0}{@shift:0}{text:"world"}]
on one button.
And i don't understand why when i press the buton first time the state change immediatly and when i press the button a second time it takes about a second . and then press again :change immediatly and again : 1s ... is it intended to do that or is it a bug ?
i say that because if i remove the {@shift:1} action , the state change immediatly.

thanks !

I have tested your code and it works perfectly in my stream deck.

What is {@shift:1} doing?

If you have some other script that is reacting to that, it will be executed immediately, and if that script is doing something that takes a long time, it will look as if this script is the one delaying things.

Oh ! Thanks for your help both ! now i see why. 

The {@shift:1} state is tested on other buttons on my template and there are 20 test of them on the screen to get triggered differently if shift is on 1 or 0 .

i removed all those button and the @shift button goes faster and faster as  the number of other buttons decreases.
It's like the variable is tested globally before anything on each button. 


The purpose of my template is to have a pseudo "shift" button that will help me trigger other button on the screen differently if the @shift variable the "shift" button  is 0 or 1 .



But all other button than "shift"  , have 2 condtions to be tested for each button . The first is (press) and the second is the @shift value. Then things happen only when the button is pressed? After , it depends of the "@shift" variable.


Would it be possible to not execute the test of the variable before the button is pressed ?
then it would certainly accelerate the behavior of the "shift" button .
Or is it my streamdeck not working correctly ? i do not know .


And yes there some "wait" involved on other button . Because i use the shift state to trigger button that have different behavior on one button depending on the time i release those . i use clyphx pro and a G-controls script .

The G-control Script have a function that allow me send 1 message when i release immediately , and another one when i delay the release .


here is an more extensive explanation :

Code:

#********************************** [SETTINGS NOTES] **********************************

# Please DO NOT change any of the spacing in this file.

# Please DO NOT change the name of this file or its file extension.  When done making
# your changes to the settings below, just save the file.

# After saving this file, you will need to load a new Live Set/reload the
# current Live Set for your changes to take effect.


#********************************** [SETTINGS] *****************************************

# Below you can specify a list of MIDI Buttons to use as G-Controls as well as the Action
# Lists they should trigger when various gestures are received. The MIDI Buttons you
# specify here are expected to be momentary (send an on message when pressed and an
# off message when released).

# The entry format for each control is:
# NAME = TYPE, CHANNEL, NOTE_OR_CC, OFF_LED, ON_LED, REPEAT

# --------------------------------------------------------------------------------------
# | ENTRY      |  DESCRIPTION
# --------------------------------------------------------------------------------------
# | NAME       |  A unique one-word name for the control.
# --------------------------------------------------------------------------------------
# | TYPE       |  The type of MIDI message the control sends (NOTE or CC).
# --------------------------------------------------------------------------------------
# | CHANNEL    |  The MIDI Channel number in the range of 1-16.
# --------------------------------------------------------------------------------------
# | NOTE_OR_CC |  The Note or CC number in the range of 0-127.
# --------------------------------------------------------------------------------------
# | OFF_LED    |  The LED value in the range of 0-127 to use by default and when the
# |            |  control is not pressed down. If in doubt, use 0.
# --------------------------------------------------------------------------------------
# | ON_LED     |  The LED value in the range of 0-127 to use when the control is pressed
# |            |  down. If in doubt, use 127.
# --------------------------------------------------------------------------------------
# | REPEAT     |  TRUE or FALSE to indicate whether the control should repeatedly trigger
# |            |  an Action List when it's pressed down.
# --------------------------------------------------------------------------------------

# Example: MY_BTN1 = NOTE, 1, 10, 0, 127, FALSE


# After each control specification, you'll list the gestures you want to listen for and
# the Action List that should be triggered when the gesture is received.

# The entry format for each gesture is:
# NAME GESTURE_TYPE = ACTION_LIST

# --------------------------------------------------------------------------------------
# | ENTRY        |  DESCRIPTION
# --------------------------------------------------------------------------------------
# | NAME         |  The name specified for the control
# --------------------------------------------------------------------------------------
# | GESTURE_TYPE |  The type of gesture to listen for.  These types are listed below.
# --------------------------------------------------------------------------------------
# | ACTION_LIST  |  The Action List to trigger when the gesture is received.
# --------------------------------------------------------------------------------------

# Example: MY_BTN1 PRESSED = METRO


#******************************** [GESTURE TYPES] ***************************************

# --------------------------------------------------------------------------------------
# | TYPE                 |  DESCRIPTION
# --------------------------------------------------------------------------------------
# | PRESSED              |  Received when the control is pressed. The Action List
# |                      |  specified for this gesture is the one that will be repeated
# |                      |  when REPEAT is TRUE.
# --------------------------------------------------------------------------------------
# | PRESSED_DELAYED      |  Received when the control is pressed down for 500 ms or more.
# --------------------------------------------------------------------------------------
# | RELEASED             |  Received when the control is released. This will be received
# |                      |  any time the control is released and will be received before
# |                      |  the next two gesture types.
# --------------------------------------------------------------------------------------
# | RELEASED_IMMEDIATELY |  Received when the control is released after being pressed
# |                      |  down for less than 500 ms.
# --------------------------------------------------------------------------------------
# | RELEASED_DELAYED     |  Received when the control is released after being pressed
# |                      |  down for 500 ms or more.
# --------------------------------------------------------------------------------------

# Below is an example list that has been commented out (the # at the beginning of
# a line makes the line a comment). Your list should be formatted in the same way
# except without the # at the beginning of each line.

# B1 = NOTE, 9, 9, 25, 52, FALSE
# B1 PRESSED = MUTE
# B1 RELEASED_DELAYED = MUTE

If other scripts have wait actions, everything will wait, I'm afraid. I have considered making script execution asynchronous, but that would lead to all kinds of concurrency problems and race conditions.

But there's something odd going on here. You say the other scripts have two events, a (press) and a (@shift) event. Those commands should NOT be executed unless you press that button, regardless of changes to the @shift variable. If they do, it's a bug. In that case, I would say it's a pretty serious bug.

Can you please share another script that references the @shift variable and has a wait action? If I can reproduce the problem, I can see what is going on.

yes of course !
the shift button is 

[(init){@shift:0}]
[(press){state:1}{@shift:1}{text:"hello"}]
[(press){state:0}{@shift:0}{text:"world"}]

all other buttons depending on the shift state are a multiaction : with this structure



first midi script , the upper one is:
[(press)(@shift:0){cc,16,41,127}]
[(release)(@shift:0){cc,16,41,0}]
[(press)(@shift:1){cc,16,41,127}]

and second midi script the bottom one is :
[(release)(@shift:1){wait:200}{cc,16,41,0}]

the native stream deck delay (Customizable Multi Action Delays) are 20ms for both wirtual keypress and nex action.

there are 11 button like this depending of the shift state .

I just made a test with one shift button with this code :

[(init){@shift:0}]
[(press){state:1}{@shift:1}{text:"hello"}]
[(press){state:0}{@shift:0}{text:"world"}]


 and 10 script buttons with this one .
[(press)(@shift:0){cc,16,41,127}]
[(release)(@shift:0){cc,16,41,0}]
[(press)(@shift:1){cc,16,41,127}]
[(release)(@shift:1){wait:200}{cc,16,41,0}]



I confirm that the shift button is really slow and certainly test the shift state of other scripts even if ,as you explained, it should not test the shift state if the button is note pressed not released .


to be more clear , the shit button trigger immediatly when pushed first time , but does not trigger immediatly (depending of the number of the other button) when i pressed again to "unshift"   


ps:no multiaction involved here .

i just made a small video about the bug :
https://www.youtube.com/watch?v=R_nIMKwuD-o
hope it will help .
Thanks !

Thanks.

There is a bug in the (release) event.

Do you really need (release) events, or could you do it with just (press) events?

This command:

[(release)(@shift:1){wait:200}{cc,16,41,0}]

...would do exactly the same thing if it was...

[(press)(@shift:1){wait:200}{cc,16,41,0}]


And these commands:

[(press)(@shift:0){cc,16,41,127}]
[(release)(@shift:0){cc,16,41,0}]
[(press)(@shift:1){cc,16,41,127}]
[(release)(@shift:1){wait:200}{cc,16,41,0}]

...could possibly be redesigned like this:

[(press)(@shift:0){cc,16,41,127}{cc,16,41,0}]
[(press)(@shift:1){cc,16,41,127}{wait:200}{cc,16,41,0}]

Oh  thanks ! Now that i know what is the problem , yes ,i will adapt the template in purpose !
To be honest at the beginning i used the shift button like this

[(init){@shift:0}]
[(press){state:1}{@shift:1}]
[(release){state:0}{@shift:0}]

the goal was ; While i keep shift pushed i can use the second behavior of all button and when i realease shift i could use the first one . 

But it was not working correctly . the shift was release before i removed my finger or something that made the behavior of other buttons strange .

Then i decide to just use the shift button as a toggle than a momentary button.

I think now that it was part of the (release) bug that made shift button work incorrectly.

Thank you a lot !

I adapted all my buttons and it works flawessly !
I used the momentary state button for the shift button .

[(init){@shift:0}]
[(press){state:1}{@shift:1}]
[(release){state:0}{@shift:0}]

Then the behavior works perfectly ! certainly because there is only one (release) event remaining now .
all others buttons are just (press) as you explained . And it works perfectly !!
Thanks so mutch !