(timer) scripting event

TIMER DEFINITION

The wish is to have a new event called (timer) to calculate the time for its contiguous events. This command would be valid only combined with other events. It would give an error as a single event.

Two options available, "less than" and "more than":

(timer:<milliseconds)
(timer:>milliseconds)

(timer:<1001) would check during 1 second if the multi-events conditions are true or not. When conditions are true, actions are executed and timer stops. When conditions are false, actions are not executed and timer keeps running. After 1 second, timer stops and no actions are executed.

(timer:>1000) would check after 1 second if the multi-events conditions are true or not. If conditions are true, actions are executed immediately and timer stops. If conditions are false, no actions are executed and timer stops.

In all cases, when timer stops, its value is reset to 0.


PRESS+TIMER

Combined with the press event, it would allow us to configure easily press& release and press & hold actions. We could do two actions easily with just one button.

The following example executes action 1 if we keep the button pressed less than 1 second, or it executes action 2 if we keep the button pressed for 1 second or more. If action 1 is executed, it is executed when we stop pressing the button. If action 2 is executed, is executed exactly one second after pressing the button.

[(press)(timer<1000){action1}]
[(press)(timer>999){action2}]


CUSTOM VARIABLES+TIMER

This combination would be very versatile. Among other things, I think we could control single press, double press, triple press, etc. The following example would count how many times the button is pressed in 1 second:

[(init){@counter:0}]
[(press){@counter:#@counter# + 1}]
[(@counter:1)(timer>999){@counter:#@counter# + 100}]
[(@counter:101){@counter:0}{action1}]
[(@counter:102){@counter:0}{action2}]
[(@counter:103){@counter:0}{action3}]
[(@counter:>103>){@counter:0}]
[(@counter:>0>){@counter:0}]


MIDI MESSAGES + TIMER

This combination could also be useful; i.e. to control if a cc value is constant and don't change for a period of time:

[(cc:1,1,127)(timer:>1000){action1}]


TIMER CANCELLATION

The action {timer:kill} would stop the timer and reset it to 0 and stop the analysis of the multi-events conditions.
This action increases the possibilities of more complex configurations. For example, we could control press&release and press&hold actions using custom variables:

[(init){@counter:0}]
[(press){@counter:#@counter# + 1}]
[(release){@counter:#@counter# + 50}{timer:kill}]
[(@counter:1)(timer>999){@counter:#@counter# + 500}]
[(@counter:51){@counter:0}{action1}]
[(@counter:>501>){@counter:0}{action2}]


LAST COMMENTS

This event can be very useful for current scripting functionalities, but also for the future, when we can script faders and vpots in buttons, and also scripting all the dials possibilities (screen taps, press dial, press and rotate, etc.)

I suppose nobody would use more than one timer running at the same time in the same script, but it could happen. So please take in consideration how many running timers per script you would allow if you implement this new event. If you limit the quantity i.e. to four timers per script, then the available commands could be numbered:
(timer1:>100) {timer1:kill} (timer2:>100) {timer2:kill} (timer3:>100) …

A command like [(press)(timer:>500<1001){actions}] would execute actions if the button is pressed more than 500 milliseconds and less than 1 second. This would increase the options for users configuration.

Thanks for the thorough description. I can see the benefit of a solution that performs the actions you describe, but I'm not fond of the suggested syntax. It breaks the rules for press commands a bit, and having timers on received midi may be a nightmare.

I will have it in a background process for a while and see if I can come up with something similar that fits the syntax better and is reasonably "simple" to implement.

Yes, I see your point. I fully agree with you.

I also think it's a very bad idea to have one timer or more per script. It would be better to only have a few global timers for all the plugin.

Let me propose a different approach.

Imagine four global timers, numbered from 1 to 4 and we can manage them as a physical timer. We can run them, pause them, and edit their values. We can do that with actions.

So we could write this code to control single, double, and triple press per second:

(init) {timer1:pause} {timer1:0} {@counter:0}
(press) {timer1:run} {@counter:#@counter# + 1}
(timer1:1000) (@counter:1) {single press action}
(timer1:1000) (@counter:2) {double press action}
(timer1:1000) (@counter:3) {triple press action}
(timer1:1001) {timer1:pause} {timer1:0} 


The following code could control a triple state of press&release:

(init) {timer2:pause} {timer2:0} {@pressDuration:0}
(press) {timer2:run}
(release) {@pressDuration:#timer2#} {timer2:pause} {timer2:0} 
(@pressDuration:<250) {@pressDuration:0} {press action}
(@pressDuration:>999) {@pressDuration:0} {very long press action}
(@pressDuration:>500) {@pressDuration:0} {long press action}


We could go further and control a single or double press per second, or a long press for more than one second in a single button:

(init) {timer1:pause} {timer1:0} {@pressCounter:0} {@releaseCounter:0}
(press) {timer1:run} {@ pressCounter:#@ pressCounter# + 1}
(release) {@ releaseCounter:#@ releaseCounter# + 1}
(timer1:1000) (@ pressCounter:1) (@releaseCounter:0) {long press action}
(timer1:1000) (@ pressCounter:1) (@releaseCounter:>0) {single press action}
(timer1:1000) (@ pressCounter:2) {double press action}
(timer1:1001) {timer1:pause} {timer1:0} {@pressCounter:0} {@releaseCounter:0}


The value of any timer could be edited when it's paused or when it's running, using maths and variables:
{timer1: 100}
{timer1: #timer1# + 200}
{timer1: @myvalue}

A "reset" order would be also useful: {timer1:reset} would execute {timer1:pause} {timer1:0}

I hope this small brainstorming could help!! 
Thanks as always!!

Thanks. That syntax makes much more sense, I think.  

I'll put it on the wish list. There's still much to do with the generic midi button, which I prioritize.