Scripted dial alpha

It seems that the timer event is broken. 

As example, the title is not changing when the timer arrives to 1000 in the following example:

[(@t_looper:1000) {title:LOOPER END}]


... Or maybe the timers are not running ...

jordikt wrote:I am starting to play with the new scripted dial. 

Two issues detected:

- Dial Rotate: Setting "Value Display" to "Cubase/Nuendo 12dB" doesn't work. The plugin shows the number value (0-127). The issue happens with any dB value.

- Dial Rotate While Pressed: Setting "Value Display" to "None" doesn't work correctly. It removes the value from the display and shows a blank value.

Great, thanks. I've found it.

jordikt wrote:I miss a differentiation for release when dial is rotated-and-not-pressed and rotated-while-pressed.

The release event is triggered when you physically release (=unpress) the dial after having it pressed (not releasing it after rotation), so a "release after not being pressed" is not possible.

Admin wrote:

jordikt wrote:I miss a differentiation for release when dial is rotated-and-not-pressed and rotated-while-pressed.

The release event is triggered when you physically release (=unpress) the dial after having it pressed (not releasing it after rotation), so a "release after not being pressed" is not possible.

 .... You're right, what a crazy thing I was asking for!!!!!!

jordikt wrote:It seems that the timer event is broken. 

As example, the title is not changing when the timer arrives to 1000 in the following example:

[(@t_looper:1000) {title:LOOPER END}]

... Or maybe the timers are not running ...

I agree that the addition of the action "title" may be confusing. "title" is only used for faders and vpots on dials, where you need to distinguish between the the title and the value.

I assume you use a button, and then you need to use {text:LOOPER END}

No, I mean that the timers are not working anywhere.

I don't know if the problem is that the timers are not starting (running), or if the timer event is not working.

I am experiencing a problem with the rotate while pressed action.

I have this code to move the 1st fader of Cubase when the dial is rotated unpressed and when the dial is rotated while pressed:

[(rotate:pn) {pb:1,#@e_value#}]
[(pb:1,*) {value:#@e_pbvalue#} {title:#@e_pbvalue#}]

The problem I have is when the dial is rotated while pressed: the initial value is not matching the correct initial value. Am I missing something?

- - -

I see in the help web page that fader/vpot/value actions are all synonyms, but there is no script action to set the value of the secondary bar. I suppose this is the problem I am experiencing.

- - -

It would be probably useful to change the three actions for only two actions: one action for unpressed rotation values, and another one for pressed rotation values.

In the case you like the idea of only two actions:

Names for unpressed rotation value could be:
{mainvalue:_value_}
{primaryvalue:_value_}

Names for rotation while pressed value could be:
{secondvalue:_value_}
{secondaryvalue:_value_}
{pressedvalue:_value_}

"Avoid handle/text collision" menu is missing when selecting "Title at the top/Value at the fader" or "Value at the top/Title at the fader"

jordikt wrote:No, I mean that the timers are not working anywhere.

I don't know if the problem is that the timers are not starting (running), or if the timer event is not working.

I used your script and changed "title" to text", and it works perfectly. I have tested on both the Generic Midi button and the scripted dial.

[(press){text:#none#}{@t_looper:restart}]
[(@t_looper:1000) {text:LOOPER END}]

jordikt wrote:"Avoid handle/text collision" menu is missing when selecting "Title at the top/Value at the fader" or "Value at the top/Title at the fader"

Got it, thanks.

jordikt wrote:I am experiencing a problem with the rotate while pressed action....

You are correct that the action to set the secondary bar is missing. I'm not keen on creating new actions for that. There are other actions that can target the pressed/secondary properties (e.g., the minmax action), and there I added a ",p" tag in the action to target the action to the pressed/secondary functions (as for the events). I haven't had time to update the documentation, but I will do it right away. Sorry.

In short:
{minmax;0,127} sets the min max values for the main fader/vpot/bar.
{minmax;p,0,127} sets the min max values for the secondary ("while pressed") bar.
...likewise...
{step:v} {step:f,10}
{step:pv} {step:pf,10}

...and a not-yet-released action to set the "Value display" dropdown from the script:
{valuedisplay:_name_}
{valuedisplay:p,_name_}

I haven't spent much time thinking about the action to set the secondary bar position, but given the above structure, I think a similar solution is the best:
{value:_number_}
{value:p,_number_}

I have restarted everything and timers are working correctly now.

Sorry for the inconveniences...

Admin wrote:{value:_number_}
{value:p,_number_}

perfect!

jordikt wrote:I have restarted everything and timers are working correctly now.

Sorry for the inconveniences...

I have noticed that I often have to install the update twice. The first time, the message in the top right corner of the Stream Deck editor says, "Unable to install Midi plugin". I don't know if this is a problem in the Stream Deck software or if the plugin fails to release some resources.

I have fixed all (I believe) of the reported issues with this version.

The {value:p,_value_} is implemented to access the secondary bar.
The {valuedisplay:_name_} is implemented to access the value display dropdown for both the main and the secondary control.

I have updated the documentation page.

When you install this, please check the install message in Stream Deck to verify that the installation is successful.

Version 3.11.0.217

We can do single tap, double tap, and so on. Great!

[(init) {@t_tapCounter:reset} {@tapCounter:0}]
[(tap) (@t_tapCounter:0) {title:SINGLE TAP} {@t_tapCounter:restart} {@tapCounter:1}]
[(tap) (@tapCounter:1) {title:DOUBLE TAP} {@tapCounter:2}]
[(tap) (@tapCounter:2) {title:TRIPLE TAP}]
[(@t_tapCounter:1000) {@t_tapCounter:reset} {@tapCounter:0}]

I find that the letters r,p,n for release events and rotate events are a little bit confusing. I think it would be convenient if we could improve the terminology and make them easier to memorize.

1) The first point is release(r) and rotate(p). These two letters are used to define the same condition (rotate while pressed). That is a little bit confusing to me, because users have to memorize two letters for the same condition.

As we are using very often the "p" in different events and actions, I propose to use it also for release events:

release(p) = release after rotate while pressed
rotate(p) = rotate while pressed

2) The second point is the "n" for release and rotate events. In this case, we have one letter that define two different conditions: not rotated for release and not pressed for rotate. Also these definitions are not very intuitive as they are negative sentences (it's more difficult to memorize them).

We could keep the "n" but changing its definition to "normal", so we would get:

release(n) = release after normal press (not rotated)
rotate(n) = normal rotation (not pressed)

And we would have two clear antonyms here: 

- normal press versus press and rotated
- normal rotation versus rotation while pressed

- - -

The result of these changes would be these events:

release(n)
release(p)
rotate(lrnp)

- - -

In the editor, all labels of all dial options could be renamed like this:

Normal dial rotation
Pressed dial rotation

Version 3.11.0.217:

- dB values are shown correctly now, but only when min/max are 0-127. If I set them to 0-16383, the dB values are not shown.

- "Avoid handle/text collision" menu should be hidden when "Title and Value at the top" is selected.

- Value Display "Controlled by script" is not working when "Title and Value at the top" is selected.

- Timers seems to be not allowed with release events according to this error message. I don't know if this is correct:

The property I miss a lot in the new dial scripting is the option to get the lcd names of mackie controls (#LCDU# and #LCDL#).

I wonder if it would be possible to implement something like this:

[(init) {title:#LCDL1#}]

We could use #LCDU1# to #LCDU9# and #LCDL1# to #LCDL9# to get the lcd names of all channels.

If this addition is possible, it would be great to implement it also for Generic Midi Scripted Button/Fader/Vpot.

From website help:

"The (tap) event is a single event thing, i.e., there isn't any logic like the (press) event where you can have different things happening the first, second, third tap and so on. I'd like to hear if you think this is a significant drawback."

IMO, the (tap) event must be a single event, as it is now.

Variables can change the actions of the taps, so users that want this behaviour can define them easily:
[(init){@tapping:1}]
[(tap)(@tapping:1){title:FIRST TAP}{@tapping:2}]
[(tap)(@tapping:2){title:SECOND TAP}{@tapping:3}]
[(tap)(@tapping:3){title:THIRD TAP}{@tapping:1}]

1) I think that the "p" to set the stepsize for the secondary bar should be with a comma ("p,") as the rest of actions that allows this optional "p" are all with comma.

2) It would be useful to add a "toggle" option to alternate on and off large icons: {largeicons:toggle}

I can definitely consider changing the indicators if we find something more logical, but I don't agree with all your suggestions.

jordikt wrote:1) The first point is release(r) and rotate(p). These two letters are used to define the same condition (rotate while pressed). That is a little bit confusing to me, because users have to memorize two letters for the same condition.

These events are not for the same condition.  
release(r) is triggered when you release the dial after having rotated it.
rotate(p) is triggered when you rotate the dial while it is being pressed.

jordikt wrote:release(p) = release after rotate while pressed
rotate(p) = rotate while pressed

A release event can only be triggered after the dial has been pressed, so release(p) makes no sense. What is important to know when the dial is released is whether it has been rotated or not, and I don't think "p" is a logical indicator for "has been rotated".

jordikt wrote:2) The second point is the "n" for release and rotate events. In this case, we have one letter that define two different conditions: not rotated for release and not pressed for rotate. Also these definitions are not very intuitive as they are negative sentences (it's more difficult to memorize them).

We could keep the "n" but changing its definition to "normal"...

I disagree. "not rotated" says exactly what it is. "normal rotated" depends on your personal opinion on what is "normal".

jordikt wrote:The property I miss a lot in the new dial scripting is the option to get the lcd names of mackie controls (#LCDU# and #LCDL#).

I wonder if it would be possible to implement something like this:

[(init) {title:#LCDL1#}]

We could use #LCDU1# to #LCDU9# and #LCDL1# to #LCDL9# to get the lcd names of all channels.

If this addition is possible, it would be great to implement it also for Generic Midi Scripted Button/Fader/Vpot.

I agree that it would be nice to have this feature, but it requires quite some changes to the script engine. The lcd names are only available in the Mackie Control protocol, and the script engine isn't attached to the Mackie driver at all. Maybe sometime in the future...

jordikt wrote:1) I think that the "p" to set the stepsize for the secondary bar should be with a comma ("p,") as the rest of actions that allows this optional "p" are all with comma.

Yes, I agree. I have also considered changing the rotate event to have the optional p/n comma separated from the l/r indicator to have a consistent "p," everywhere.

jordikt wrote:2) It would be useful to add a "toggle" option to alternate on and off large icons: {largeicons:toggle}

Great suggestion.

jordikt wrote:- dB values are shown correctly now, but only when min/max are 0-127. If I set them to 0-16383, the dB values are not shown.

Thanks, I'll check that.

jordikt wrote:- "Avoid handle/text collision" menu should be hidden when "Title and Value at the top" is selected.

Of course.  

jordikt wrote:- Value Display "Controlled by script" is not working when "Title and Value at the top" is selected.

It is, but this is another area of confusion about the text/title actions. With "Title and Value at the top" selected, the title is displayed when the dial is idle, so you need to use the title action to see any change. The value text is changed if you use the text action, but you will see the text only when the dial is rotated.

jordikt wrote:- Timers seems to be not allowed with release events according to this error message. I don't know if this is correct:

It is correct. Both events are "instant" events that cannot be triggered simultaneously.  If you need to distinguish between the dial/button being pressed while the timer triggers, I'm afraid you need to solve that in the script by keeping the pressed state in a variable.

Admin wrote:
It is, but this is another area of confusion about the text/title actions. With "Title and Value at the top" selected, the title is displayed when the dial is idle, so you need to use the title action to see any change. The value text is changed if you use the text action, but you will see the text only when the dial is rotated.

I'm not sure I catch the last sentence here ... but i wanted to report what I think is a bug.

• I have observed that if you select Display="Horizontal bar" then you see the Title and the value on two lines, which is fine.
  
• I was trying to mimic the same with selecting Display="Fader", "Title and Value at the top", and using a custom design with the upper half of the images (Background and Handle)  made transparent, but unfortunately it does not work. Only the title is displayed.
  

My understanding is that "value" only control the handle position and the @e_value variable while you can put anything you want in the "text". Is it correct ?

Now, is there a way to have it working like the horizontal bar with a custom fader display (and preferably using "text" rather than "value"),
... or better and more generally speaking, to have two lines of text (with for instance CHAR(10) for what is displayed at the top ?