3.10.0.5 beta / 3.11 alpha

The Value statements should have a "midivalue" attribute, but it is misspelled as "midvalue",

Admin wrote:The Value statements should have a "midivalue" attribute, but it is misspelled as "midvalue",

 just updated the file trying to adjust the values to the windows volume control.

Yes, that worked better.

Is the purpose of his file to get rid of the "%" sign you get if you select the "Percent" option?

Admin wrote:Yes, that worked better.

Is the purpose of his file to get rid of the "%" sign you get if you select the "Percent" option?

Yep, as windows sound volume always is displayed as a value 0-100.

I have been configuring a scripted button for doing different actions depending if the button is pressed one, twice or three times in a period of 2 seconds, using the new timer functions.

I am experiencing three problems. I explain the first one in this post, and the other two issues in another post.

To reproduce the first issue, please configure three buttons with the following scripts:

BUTTON 1
[(init) {text:Reset\nTimer}]
[(press) {@t_pressCounterOne:reset} {text:Pause\nTimer}]
[(press) {@t_pressCounterOne:pause} {text:Reset\nTimer}]

BUTTON 2
[(init) {text:Show\nValues}]
[(press) {text:Timer\n#@t_pressCounterOne#\n\nCounter\n#@pressCounterOne#}]

BUTTON 3
[(init) {@pressCounterOne:0} {text:Counter\nInitial\nValue\n#@pressCounterOne#} {@t_pressCounterOne:reset}]
[(press) (@pressCounterOne:0) {@pressCounterOne:1} {text:Press1\n#@pressCounterOne#} {@t_pressCounterOne:start}]
[(press) (@pressCounterOne:1) {@pressCounterOne:2} {text:Press2\n#@pressCounterOne#}]
[(press) (@pressCounterOne:2) {@pressCounterOne:3} {text:Press3\n#@pressCounterOne#}]
[(@t_pressCounterOne:2000) {text:#@t_pressCounterOne#} {@pressCounterOne:#@pressCounterOne+100#} {@t_pressCounterOne:reset}]
[(@pressCounterOne:101) {text:Counter\nResult\n#@pressCounterOne#\nSingle\nPress} {@pressCounterOne:0}]
[(@pressCounterOne:102) {text:Counter\nResult\n#@pressCounterOne#\nDouble\nPress} {@pressCounterOne:0}]
[(@pressCounterOne:103) {text:Counter\nResult\n#@pressCounterOne#\nTriple\nPress} {@pressCounterOne:0}]

The first button alternates a "reset timer" and a "pause timer" action on every press.
The second button shows the current value of the timer every time is pressed.
The third button registers if the button is pressed once, twice or three times in a period of two seconds.

Please see this video:
https://youtu.be/0I2hMze77yo

Video second 0-18: I switch page back and forth to reload the scripts every time I press the third button once, twice and three times. The button reacts perfectly to the press actions, showing messages of single press, double press, and triple press.

Video second 19-34: I press the third buttons twice, and it shows the text "double press". That's the correct behaviour. I don't switch the page this time, and I press the button twice again. The button doesn't show the text "double press" because the timer is above 2 seconds. I press the second button repeatedly to show the timer value. It shows 4 seconds at the first press and around 10 seconds at the last press.

Video second 35-40: I press the first button to reset the timer and then I press the second button to update the timer value. The timer should be stopped and reset to zero, but it shows 14 seconds and it keeps running.

Video second 41-43: I press the first button to pause the timer and then I press the second button to update the timer value. The timer should be stopped, but it keeps running.

Video second 44-47: I press the first button again to reset the timer, but it doesn't work.

Video second 48-60: I go back and forth of the page and I press the second button to show timer values. It is running and not reset, even there is an (init) event in the third button to reset the timer. I press the first button repeteadly to reset or pause the timer, but the timer keeps running and increasing its value.

Video second 61-65: I press twice the third button. The button detects the double press and it shows the correct message. Then I press the second button and the timer changes from 37727 ms to 2793 ms. The timer has been reset correctly.

Video second 65-75: I press twice the third button. The button doesn't detect the double press. Then I press the second button repeatdely and the timer is running and not reset.

The other issues are related to variables and timer events as part of multi-events.

The following code is similar to the code of the third button of the previous post. It should work for detecting single, double or triple press:

[(init) {@pressCounterTwo:0} {text:Counter\nInitial\nValue\n#@pressCounterTwo#} {@t_pressCounterTwo:reset}]
[(press) {@pressCounterTwo:#@pressCounterTwo+1#} {text:Counter\n#@pressCounterTwo#} {@t_pressCounterTwo:start}]
[(@t_pressCounterTwo:2000) (@pressCounterTwo:1) {@t_pressCounterTwo:reset} {@pressCounterTwo:0} {text:Single\nPress}]
[(@t_pressCounterTwo:2000) (@pressCounterTwo:2) {@t_pressCounterTwo:reset} {@pressCounterTwo:0} {text:Double\nPress}]
[(@t_pressCounterTwo:2000) (@pressCounterTwo:3) {@t_pressCounterTwo:reset} {@pressCounterTwo:0} {text:Triple\nPress}]

This script doesn't work. Every time the button is pressed, the value of the variable doesn't increase.

If the last three lines are removed, then the value of the variable increases correctly (though the button can't detect single, double or triple press).

That's the second issue, multi-event seems to not work.

The third problem is that variable values included in the multi-events seems to be "forbidden" in the script. Restoring the last three lines and changing the value of the variable in the init line, the code is:

[(init) {@pressCounterTwo:1} {text:Counter\nInitial\nValue\n#@pressCounterTwo#} {@t_pressCounterTwo:reset}]
[(press) {@pressCounterTwo:#@pressCounterTwo+1#} {text:Counter\n#@pressCounterTwo#} {@t_pressCounterTwo:start}]
[(@t_pressCounterTwo:2000) (@pressCounterTwo:1) {@t_pressCounterTwo:reset} {@pressCounterTwo:0} {text:Single\nPress}]
[(@t_pressCounterTwo:2000) (@pressCounterTwo:2) {@t_pressCounterTwo:reset} {@pressCounterTwo:0} {text:Double\nPress}]
[(@t_pressCounterTwo:2000) (@pressCounterTwo:3) {@t_pressCounterTwo:reset} {@pressCounterTwo:0} {text:Triple\nPress}]

The init event assigns 1 to the variable, but reloading the button will always show zero. The button will show zero if we use any of the following init lines:
[(init) {@pressCounterTwo:2} {text:Counter\nInitial\nValue\n#@pressCounterTwo#} {@t_pressCounterTwo:reset}]
[(init) {@pressCounterTwo:3} {text:Counter\nInitial\nValue\n#@pressCounterTwo#} {@t_pressCounterTwo:reset}]

If we set the variable to 4, the value is shown correctly, and if we press the button the value increases accordingly:
[(init) {@pressCounterTwo:4} {text:Counter\nInitial\nValue\n#@pressCounterTwo#} {@t_pressCounterTwo:reset}]

If we set the variable to -10, then the value is shown correctly, and if we press the button, the value increases correctly, until it arrives to zero. Once the value is zero, pressing the button doesn't increases the value:
[(init) {@pressCounterTwo:-10} {text:Counter\nInitial\nValue\n#@pressCounterTwo#} {@t_pressCounterTwo:reset}]

I've find another issue. Timers are running after restarting the device. I have done the following steps in the following order:

Step 1
I restart my Stream Deck quitting Elgato Stream Deck software and unplugging the USB cable. The two timers used in my setup start to run from zero.
The timers are @t_pressCounterOne and @t_pressCounterTwo.
It seems that these timers are reset after restart, but not paused.

Step 2
I have removed the two buttons that has the scripts to start the timers after press events. Restarting SD+ works fine, no timers are running

Step 3
I add again the two buttons that has the scripts to start the timers after press events. I don't press any button to start the timers, and I don't restart the device. Both timers starts to run. Scripts have a reset timer action in the init, so maybe this is the cause.

Step 4
I remove the two buttons, and restart SD+. Timers are not running. I remove the reset timer actions from the scripts and I add the two scripted buttons again. The issue is not fixed, the timers are running after restarting SD+

These are the two scripts if you want to reproduce it:

Script 1
[(init) {@pressCounterOne:0} {text:Counter\nInitial\nValue\n#@pressCounterOne#}]
[(press) (@pressCounterOne:0) {@pressCounterOne:1} {text:Press1\n#@pressCounterOne#} {@t_pressCounterOne:start}]
[(press) (@pressCounterOne:1) {@pressCounterOne:2} {text:Press2\n#@pressCounterOne#}]
[(press) (@pressCounterOne:2) {@pressCounterOne:3} {text:Press3\n#@pressCounterOne#}]
[(@t_pressCounterOne:2000) {text:#@t_pressCounterOne#} {@pressCounterOne:#@pressCounterOne+100#} {@t_pressCounterOne:reset}]
[(@pressCounterOne:101) {text:Counter\nResult\n#@pressCounterOne#\nSingle\nPress} {@pressCounterOne:0}]
[(@pressCounterOne:102) {text:Counter\nResult\n#@pressCounterOne#\nDouble\nPress} {@pressCounterOne:0}]
[(@pressCounterOne:103) {text:Counter\nResult\n#@pressCounterOne#\nTriple\nPress} {@pressCounterOne:0}]

Script 2
[(init) {@pressCounterTwo:0} {text:Counter\nInitial\nValue\n#@pressCounterTwo#}]
[(press) {@pressCounterTwo:#@pressCounterTwo+1#} {text:Counter\n#@pressCounterTwo#} {@t_pressCounterTwo:start}]
[(@t_pressCounterTwo:2000) (@pressCounterTwo:1) {@t_pressCounterTwo:reset} {@pressCounterTwo:0} {text:Single\nPress}]
[(@t_pressCounterTwo:2000) (@pressCounterTwo:2) {@t_pressCounterTwo:reset} {@pressCounterTwo:0} {text:Double\nPress}]
[(@t_pressCounterTwo:2000) (@pressCounterTwo:3) {@t_pressCounterTwo:reset} {@pressCounterTwo:0} {text:Triple\nPress}]

Thanks for the extensive feedback. I realize I need to do some internal redesign since the results are confusing.

There are several situations where you claim the timers are running when they are not. It looks like they are running since you get updated results each time you print the timer value. The values are updated because I return the time elapsed since the timer was started, and this number increases even if the timer isn't running. Though the timer isn't running, and no timer events will be triggered.

I realize that the way I have solved it makes "reset" and "pause" do the same thing, and there is no way to continue a paused timer. I need to change the internal logic to make it work better and less confusing.

You are correct that multi-commands aren't handled correctly. I think I have fixed that, but I will do some more testing when I finish the internal redesign.

I will redesign it and then run it through your scripts to verify that it works better. Again, thanks for your invaluable feedback.

According to my tests, this version handles all your scripts correctly and behaves more logically (i.e., the timers actually stop when you stop them )

I have added a new timer action {@t_whatever:restart}
It's a combo of a reset and a start command.

Version 3.10.0.400

Version 3,10,0,400 works perfectly for all the timer actions. Restart is a nice addition.

I have been testing how the loop timer reacts to the other timer actions, and I wonder if the current behaviour is good or you would like to change it.

If you press <pause> after starting a loop timer, the result is a loop pause. If you press again a <loop> action, the timer runs again in loop mode:
1st step - init loop timer
2nd step - pause
3rd step - init loop timer

If you press <start> after <pause>, the result is an "unloop" action (he timer doesn't reset the value when the first event is triggered, and timer keeps running):
1st step - init loop timer
2nd step - pause
3rd step - start

If you init a loop timer and after that you press <start>, the result is an "unloop" action like the previous example:
1st step - init loop timer
2nd step - start

The action <restart> reacts depending to the last executed command. If the last command was <loop>, <restart> will restart the loop. If the last command was <start>, <restart> will restart an standard timer, not a loop.

The action <reset> doesn't interfere in the loop/unloop action. If the following command is <loop>, a loop will start. If the following command is <start>, an standard timer will start.

=====

I wonder if any user will need to start a timer as a looper and change it to an standard timer if some condition happens. I'm not sure, but it would have sense to allow this option.

With the current design users can change timers from standard to loop and vice versa, even it's not very intuitive that <start> cancels the loop mode.

A solution could be to add a new action to unloop the timers, and make that <start> starts a timer without changing the loop/standard mode of the timer. The new action could be something like: {@t_whatever:unloop}

=====

I have tested the loop actions with these six scripted buttons. If you want to use them to check the loop behaviour:





Scripted button 1:
[(init) {text:Restart\nTimer}]
[(press) {@t_pressCounterFour:restart}]

Scripted button 2:
[(init) {text:Start\nTimer}]
[(press) {@t_pressCounterFour:start}]

Scripted button 3:
[(init) {text:Pause\nTimer}]
[(press) {@t_pressCounterFour:pause}]

Scripted button 4:
[(init) {text:Reset\nTimer}]
[(press) {@t_pressCounterFour:reset}]

Scripted button 5:
[(init) {@pressCounterFour:0} {text:Init\nLooper} {@t_pressCounterFour:reset}]
[(press) {@t_pressCounterFour:loop} {text:#@pressCounterFour#}]
[(@t_pressCounterFour:1000) {@pressCounterFour:#@pressCounterFour + 1#} {text:#@pressCounterFour#}]

Scripted button 6:
[(init) {@t_looperTwo:loop}]
[(@t_looperTwo:100) {text:#@t_pressCounterFour#}]
[(press) {text:showing\nvalue...} {wait:500} {text:#@t_pressCounterFour#}]

I think an "unloop" action is a bit unclear. Does it start a timer in continuous mode (i.e., equal to a "start", in which case it is unnecessary)? Or does it remove the loop flag, requiring a "start" action to start the timer (in which case it is unnecessary)?

I have considered if a "continue" action makes sense, and perhaps it does. I've also considered changing "loop" to "startloop" to clarify what it does.

Maybe like this:

• start: start a timer from 0 in continuous mode.
  
• startloop: start a timer from 0 in loop mode.
  
• pause: pause a timer.
  
• continue: continue a timer from the current value in the current mode. It works as a "start" if the timer has not been started previously.
  
• restart: restart a timer from 0 in current mode. It works as a "start" if the timer has not been started previously.
  
• stop: Stop a timer(?) It does the same thing as pause, but maybe it makes more sense from a "documentation" point of view in some scripts to stop a timer if you have no intent to continue.
  

Admin wrote:I think an "unloop" action is a bit unclear. Does it start a timer in continuous mode (i.e., equal to a "start", in which case it is unnecessary)? Or does it remove the loop flag, requiring a "start" action to start the timer (in which case it is unnecessary)?

The unloop action would change the mode from loop mode to continuous mode. If timer is running, an unloop action would keep the timer running. If timer is stopped, an unloop action would keep the timer stopped.

But I agree that the word <unloop> is unclear and not the good one.

From my point of view, the question is to change the mode of the timer on the fly. I mean to change the mode at any moment, independently from pausing/running the timer (changing the mode wouldn't stop or start any timer).

I'm not sure that changing the mode on the fly will be a very used action. If it is too complicated to implement, probably it is better to forget it. But if it is possible to implement it, it would result in a powerful timer system.

I put my two cents regarding names and actions in both scenarios:

Scenario 1: Ability to change the mode on the fly

{t_timer:cont} --> set/changes the mode to continuous mode. It doesn't pause or start timers. Mode by default.
{t_timer:loop} --> set/changes the mode to loop mode. It doesn't pause or start timers.
{t_timer:run} --> like <start>, runs the timer in the selected mode. If mode is undefined, it is set to continuous.
{t_timer:pause} --> pauses the timer in the selected mode.
{t_timer:reset} --> resets the timer in the selected mode and pauses the timer immediately.
{t_timer:restart} --> resets the timer in the selected mode and runs the timer immediately.

Scenario 2: Not possible to change the mode on the fly

{t_timer:start} --> start a timer from 0 in continuous mode.
{t_timer:startloop} --> start a timer from 0 in loop mode.
{t_timer:run} --> resume a timer from the current value in the current mode. It works as a "start" if the timer has not been started previously.
{t_timer:pause} --> pause the timer in the selected mode.
{t_timer:reset} --> reset the timer in the selected mode, pausing the timer immediately.
{t_timer:restart} -->restart a timer from 0 in current mode. It works as a "start" if the timer has not been started previously.

====

{t_timer:run} could also be {t_timer:resume}, but I find that <run> is the best word to resume or start a timer.

{t_timer:stop} seems a confusing/duplicated action to me.

Jumping into the discussion ... What is the difference between continuous and loop mode ?
No offense of course but I think we don't need much complexity.
Most users would expect the following :

• Start (3 parameters: Initial delay, "one time" or # of counts or "infinite/loop", repeating delay if not "one time")
  
• Stop (or Kill if you prefer)
  

.. and the timer event to trigger.

thx538 wrote:Jumping into the discussion ... What is the difference between continuous and loop mode ?

{@t_whatever:loop} The action will start the timer in "loop mode". Loop mode means that the timer will run until it reaches the first registered event, fire the event, reset the timer, and start over. An event like (@t_whatever:1000) will be triggered once every second. A timer in loop mode can have only one event limit, i.e., you cannot have one event triggering at 1000 and another at 2000. Since the timer will restart when it reaches the 1000 event, it will never reach the 2000 event.

Loop mode is a powerful action, but it is true that we could do the same loop with the basic commands, removing the <loop> action:

[ (press) {@t_mytimer:reset} {@t_mytimer:start} ]
[ (@t_mytimer:1000) {text:trigger_something} {@t_mytimer:restart}]

Removing the loop commands would keep things easy and simple. We would need only 4 commands:

{t_timer:run} --> start a timer from 0 or resume a timer from the current value.
{t_timer:pause} --> pause a timer.
{t_timer:reset} --> set a timer to 0, pausing the timer immediately if it's running.
{t_timer:restart} -->restart a timer from 0. It works as a "run" if the timer has not been started previously.

Interesting.

Yes, it may be a better solution to remove the loop command. As you say, it is possible to create a loop DYI and it will be more flexible, and the timer object would be less complex.

Version 3.10.0.408

I have made the timer changes discussed in the previous post, i.e., removed the loop action, and the remaining actions are:

{t_timer:run} --> start a timer from 0 or resume a timer from the current value.
{t_timer:pause} --> pause a timer.
{t_timer:reset} --> set a timer to 0, pausing the timer immediately if it's running.
{t_timer:restart} -->restart a timer from 0. It works as a "run" if the timer has not been started previously.

You need to adjust your scripts accordingly.

In addition, I have fixed some minor bugs and visual discrepancies.

Now, I need to take a look at the fader designs that are included. I just made a quick conversion of the dial fader designs, and I'm not sure it is the best set of fader designs for the buttons.

Confirmed that the four available timer actions works perfectly.

Scrub wheel works fine also.

Vpot "auto-change direction at end positions" switches the direction on release smoothly. This option takes one single line in the UI on Mac.

It's a very subjective question of taste, but IMO the current set of fader designs is good enough. The "gradient strip" is the only one I don't like.

Generic Midi > Scripted Fader > State Icon takes two lines on MacOS

It seems that there is an issue when changing designs for scripted faders and scripted vpots in some cases:

1. I have two scripted faders combined. The scripts of these faders don't include any action to change the fader design. I usually can change the design from the dropdown menu, but sometimes the dropdown menu doesn't work. I can't reproduce this issue when I want, I don't know what is the reason that causes the "freezing" state of the design. You can see the issue here.

2. In the other hand, I have a single scripted vpot. The script of this vpot has actions to change the design, even inside an "init" event. In this case, I can never change the design using the dropdown menu. You can see this behaviour here.

3. Finally, I have another single scripted vpot, with a very simple script that doesn't change the design. In this case, the changing of vpot designs works always fine, no issues.

I think the only issue is the first one. The behaviour in the second case seems a correct behaviour to me, though the dropdown menu fails.

My two cents of how the Midi plugin could react in these cases:

- If the script has actions to change designs, remove all the design options from the dropdown menu and show only the menu item "Controlled by script"

- If the script has no actions to change designs, show the whole dropdown menu and allow the normal change of designs by selecting them in the menu

I am trying the combination of two scripted vpots. I guess that the recommended configuration for this combination is to set the upper vpot to rotate clockwise and the lower vpot to rotate counterclockwise. This configuration works fine.

Another configuration is to set one or two combined vpots to rotate in both ways. It also works fine, but two issues happens:

1. If I set the upper button to rotate to both ways with the three checkboxes enabled, only "Auto change direction" keeps enabled at the upper button after pressing any of the two combined buttons. It doesn't matter if the lower button is set to both ways, clockwise or counterclockwise, the checkboxes are disabled in the same way in the upper button:




2. If I set both buttons to rotate to both ways and I press one button until the limit, only the pressed button changes automatically the direction, the other one doesn't change.

There was some confusion (in the plugin) about when to use the manual design and when to use the scripted design. I think that was the cause of the ignored design change when you did it in the dropdown.

I have also felt some confusion about which design will be used when set from both the script and the dropdown, so your suggestion to disable the dropdown if design actions are present in the script is perfect. It will cause a slight problem since you can set {design:#none#} in the script, in which case the dropdown design is used, but I will ignore that problem (it can be solved by temporarily switching to non-scripted fader and changing the design, so it isn't a showstopper).

I agree there's a problem when configuring two vpots with "both ways/auto change direction". My solution is: don't. Rotation settings are not synchronized between the buttons, and this is by design. I assume that if you have two buttons, you have this because you want them to rotate in opposite directions; otherwise, a single button would do the same job. This is also why the rotation properties are not synchronized; I presume they should be different.

Version 3.10.0.411

I think there is a new issue with scripted v-pots.

I assume that if I set two v-pots as single v-pots, they should always work as not-combined v-pots.

But I am experiencing that Midi plugin turns single v-pots as combined v-pots when the two single v-pots are side by side or one over the other.

In this video you can see two v-pots with with different scripts set as single v-pots. One script has design actions. You can see that they get combined and uncombined depending on the position.

This issue is not happening in single scripted faders, only in single scripted v-pots.

=====

Due this issue, I have been thinking about the benefits of the combined v-pot. The benefit in combined faders is clear to me as they show the display of fader and vu in a bigger size. But the display of single v-pots and combined v-pots is the same, so I wonder what is the benefit of combining them.

=====

All the changes of last version works fine. No issues changing designs of the drop-down menu. Generic Midi>Scripted Fader>State Icon takes one line on MacOS.

As I see it, the only reason to use two synchronized vpots is to have one going clockwise and the other counterclockwise (remember the "both ways/auto switch direction" discussion?). I know that SideshowFX, e.g., uses this in their profiles.

I agree that synchronizing two script vpots marked as "single" is highly counter-intuitive. I'll see if I can change it so they are only synchronized if configured upper/lower.

I wonder if I have explained correctly this issue in my last post. The problem that I am experiencing is that I can not build two non-combined scripted vpots side by side from scratch. I mean that the Midi plugin always combine them, even if I don't want the combination. I have achieved two non-combined scripted v-pots side by side doing a copy-paste of both buttons from other pages. But it seems not possible if scripted v-pots are built from scratch.

If I am not wrong, combining v-pots is a new feature of this alpha version, only available for scripted v-pots. We can combine two scripted v-pots or more without using the options "single-upper-lower", so maybe these options are adding complexity to the system.

I think we are talking about the same thing.

With the Control Change action, you can define faders in pairs by making them control the same thing and set them upper/lower. With vpots, you don't really set them as pairs (i.e., they are not aware of each other); you just configure them to control the same thing.

With Generic Midi, I have automized the non-scripted faders and vpots to be aware of neighbors and automatically pair up if two buttons control the same thing.

Scripted faders and vpots have not existed before. With scripted faders and vpots, the plugin cannot determine if two buttons control the same thing, so you must set upper/lower manually. The synchronization is more than just "control the same thing", the buttons communicate events between them. Since "the other" button is not getting vpot and fader events when you press one button, the pressed button must make the other button aware of what's happening; otherwise, they would not cooperate.

The problem you have (as I understand it) is that buttons are automatically synchronized despite the fact that you configure them as "single", and I consider that a bug. If you explicitly say the button should be single, that's what it should be.