Scripted dial alpha

A new version with, hopefully, everything we have discussed. There has been a lot of discussion going on, and I've lost track of everything. But hopefully, everything is included, and I haven't broken anything with the numbering thing.

Numbers are removed.

The plugin no longer triggers (fader) and (vpot) events when the dial is at the endpoints (i.e., when the next step would have gone outside the range).

The right-click copy is implemented (with a popup!) and seems to work as expected on both Windows and macOS.

Version 3.11.0.281

Hello, two anomalies and one question below
I have the following command :
[(sysex:F0 6A XX F7){value:#e_sysexvalue#}{text:#e_sysextext#}{title:#@e_sysex#}]

{value:#e_sysexvalue#} and {text:#e_sysextext#} are rejected by the editor (Expression cannot be calculated) while {title:#@e_sysex#} works well (message display).

More generally speaking is there a way to catch a given byte of the incoming variable part as an integer (like e_sysexvalue but for the 2nd byte, 3rd byte ...) or do I have to crawl the @e_sysex variable ?

thx538 wrote:Hello, two anomalies and one question below
I have the following command :
[(sysex:F0 6A XX F7){value:#e_sysexvalue#}{text:#e_sysextext#}{title:#@e_sysex#}]

{value:#e_sysexvalue#} and {text:#e_sysextext#} are rejected by the editor (Expression cannot be calculated) while {title:#@e_sysex#} works well (message display).

More generally speaking is there a way to catch a given byte of the incoming variable part as an integer (like e_sysexvalue but for the 2nd byte, 3rd byte ...) or do I have to crawl the @e_sysex variable ?

The "@" character is missing for e_sysexvalue and e_sysextext. This works:
[(sysex:F0 6A XX F7){value:#@e_sysexvalue#}{text:#@e_sysextext#}{title:#@e_sysex#}]

I'm checking your question. I thought I knew the answer, but a (possible) bug in the math library is causing problems. I'll investigate further.

Admin wrote:The "@" character is missing

Thank you, I should have seen it  

Two other things, trying to crawl the @e_sysex variable :

1. I have a sysex (variable part) "03 06". #VALUE(MID(@e_sysex,1,2))# works well and returns 3 while #VALUE(MID(@e_sysex,4,2))# returns an error : Invalid Parameter, Expression cannot be calculated.
   
   Note that: MID(@e_sysex,4,2) is correctly evaluated to "06" as text, and also that #VALUE(MID(@e_sysex,2,1))# returns the same error Invalid Parameter, Expression cannot be calculated.
   
   
2. The action {minmax:1,#VALUE(MID(@e_sysex,1,2))#} returns an error : Wrong number of parameters. I did suppose minmax would accept variables ....
   

Admin wrote:Version 3.11.0.281

Confirmed on macOS that:
- Numbers are removed
- Right click to copy the name of the menu items works like a charm
- A popup "Copied to clipboard" is shown after copying the name of the menu item
- Title color is fixed in "Volume bar" and "Pan bar"
- The items "Volume bar" and "Pan bar" has been moved to the top of the drop-down menus
- Label "Title/Value positions" has changed to "Title/Value position"

Volume bar and Pan bar: 
I think the color selector of "Title text" should be first (left), and "Value text" should be second (right).

Admin wrote:

jordikt wrote:Regarding custom designs: It would be possible to load all the custom designs for the dropdown menus when starting the session in SD+? This would be a good improvement.

Unfortunately not. The plugin is not aware of custom design defined on other pages/profiles, so it is not possible.

jordikt wrote:What do you think of an action to load custom designs?

Let's say the action is {loadcustomdesign:_path_}

We could use it in a background script like this:

[(init) {loadcustomdesign:mypath/CubaseFaders} {loadcustomdesign:mypath/CubasePanoramas}]

This would load two custom designs at every boot of SD+, isn't it?

It makes sense?

What exactly is the functional difference between:

• {loadcustomdesign:mypath/CubaseFaders}   followed by {design:Cubase Faders}
  
• {@CubaseFaders:mypath/CubaseFaders}   followed by {design:#@CubaseFaders#}
  

Let's say I use the following script:

[(tap) {design:Cubase Faders}]

Then I tap the screen and I get the following result:

Cubase Faders is not found because, as you said, the plugin is not aware of custom designs defined on other pages/profiles.

So, the purpose of {loadcustomdesign:_path_} is to say to the plugin that this custom design exists and it must be shown in the drop-down menu.

A {loadcustomdesign:_path_} action after an (init) event in a Background Script would be useful to show in the drop-down menu all the designs the user wants to be always visible, and always from the beginning of every session of SD+.

In the other hand, {loadcustomdesign:_path_} would never change any design in the screen of Stream Deck, as this function is handled by the {design:_path_} action.

thx538 wrote:

jordikt wrote:I would say that the maximum values for turning fast the dial for doing some agressive automations in music can go between +14 and -14.
This information can be useful to update the documentation if you consider it interesting.

I tried this as a contest an could achieve a maximum value in the range of 20-22

Admin wrote:One tic is equivalent to the physical step you feel when you turn the dial. From what I can see, a complete revolution is 30 tics (or maybe 32 since this is a more even number in the binary world).

While rotating the dial, the Stream Deck software reports the tic count every 50 ms, so the max value represents the number of physical steps you can rotate the dial within 50 ms.

In my tests, I get about 12 for "normal fast", about 18 for really fast, and up to 25 when I abuse my Stream Deck.

I have tried again, and the maximum values I get turning fast the dial (abusing my stream deck) is +12 and -12.

I get about +4/-4 for "normal fast" and +7/-7 for really fast.

Why do we get so different figures? 

thx538 wrote:Two other things, trying to crawl the @e_sysex variable :
I have a sysex (variable part) "03 06". #VALUE(MID(@e_sysex,1,2))# works well and returns 3 while #VALUE(MID(@e_sysex,4,2))# returns an error : Invalid Parameter, Expression cannot be calculated.
Note that: MID(@e_sysex,4,2) is correctly evaluated to "06"

Yes, that's the case I have been looking at. There were bugs both in the math library and the plugin. Hopefully, I've sorted things out in this new version.

thx538 wrote:The action {minmax:1,#VALUE(MID(@e_sysex,1,2))#} returns an error : Wrong number of parameters. I did suppose minmax would accept variables ....

The minmax syntax check is a nightmare and was also affected by the bugs. It should work better now.

Version 3.11.0.302

jordikt wrote:Volume bar and Pan bar: 
I think the color selector of "Title text" should be first (left), and "Value text" should be second (right).

Why?

jordikt wrote:So, the purpose of {loadcustomdesign:_path_} is to say to the plugin that this custom design exists and it must be shown in the drop-down menu.

A {loadcustomdesign:_path_} action after an (init) event in a Background Script would be useful to show in the drop-down menu all the designs the user wants to be always visible, and always from the beginning of every session of SD+.

In the other hand, {loadcustomdesign:_path_} would never change any design in the screen of Stream Deck, as this function is handled by the {design:_path_} action.

So the purpose of the {loadcustomdesign:_path_} is to have the designs available in the dropdown, not available in the scripts?

Admin wrote:

jordikt wrote:Volume bar and Pan bar: 
I think the color selector of "Title text" should be first (left), and "Value text" should be second (right).

Why?

1) I think it's more intuitive, as Title is the first you see (it's at the top and the font is bigger) and Value is the second you see as it's below and the font is smaller

2) I think it matches better the design of the plugin: the first (left) color selector of Faders and V-pots are the Top text (the bigger font), and the second one (right) is the Fader text/V-pot text (the smaller font)

Admin wrote:

So, the purpose of {loadcustomdesign:_path_} is to say to the plugin that this custom design exists and it must be shown in the drop-down menu.

A {loadcustomdesign:_path_} action after an (init) event in a Background Script would be useful to show in the drop-down menu all the designs the user wants to be always visible, and always from the beginning of every session of SD+.

In the other hand, {loadcustomdesign:_path_} would never change any design in the screen of Stream Deck, as this function is handled by the {design:_path_} action.

So the purpose of the {loadcustomdesign:_path_} is to have the designs available in the dropdown, not available in the scripts?

Yeah, I see it in that way.

This action, combined with an (init) event in a background script, would add the custom designs that user wants to the dropdown menu, from the beginning of every session of SD.

IMO, this would be an improvement of the plugin editor that would improve the usability of the custom designs. 

We can compare it to the custom dB values. We always have the custom dB values in the editor from the beginning of every session of SD. We can always select them from the dropdown menu without looking for a page/profile where that custom dB file has been used. It would be great if we could have the same behaviour for custom designs.

Regarding the question if the purpose of this action is to have the custom designs available in the script, I would say no. From my point of view, the benefit is not for scripting, the benefit is for the editor and for the usability of the custom designs inside the editor.

By the way, I think that {loadcustomdesign:} is a very bad name for this action, as it can be confused with {design:}.

Probably {showmenuitem:} or {showmenudesign:} or {makemenuvisible:} would be more descriptive.

Admin wrote:
It should work better now.
Version 3.11.0.302

Yes it works better now. I can address each byte of the sysex variable part, including in minmax{} actions.

Now this new version introduces a regression in another script, where the following command: [(release:n){@g_trsc:#1-@g_trsc#}] is rejected with the error "Expression cannot be calculated (MINUS operator can only be applied to numeric)"
... with proper initialization [(init){@g_trsc:0}] in a background script.

If I change the command to [(release:n){@g_trsc:#1-VALUE(@g_trsc)#}] it works, but there's probably something to be checked with variables considered as numeric or text when initialized.

jordikt wrote:What do you think of an action to load custom designs?
Let's say the action is {loadcustomdesign:_path_}

I don't think it is a good idea. It defeats the principle of modularity between the editor and the script engine.
It's not a big deal to enter designs on the pages where you want to use it, IMHO, and there are probably other things that should have higher priority.

There is also a little annoyance with the value display.
The font is reduced (too much I think) when displaying a text as compared to displaying a number.

Number display :


Text display (Almost unreadable) :


Note that my background fader image is half transparent on the upper part and that I use "Title at the top, Value on the fader".

I would also suggest that when selecting "Do nothing" to handle text collisions, we have the option to justify the text (Left, Center, Right). It is always on the left at the moment.

I am now testing the "Rotate while pressed section" with a volume bar.
Since we don't have a {text:p,...} action what is the intended effect if we select "Controlled by script" for the (rotate while pressed) value display ?

I have the following command to receive these secondary (rotate while pressed) values from the DAW :
[(sysex:F0 6B XX F7){value:p,#VALUE(MID(@e_sysex,1,2))#}{text:#VALUE(MID(@e_sysex,1,2))#}{minmax:p,1,#VALUE(MID(@e_sysex,4,2))#}]
... but it overrides the main text display while it should do so only when the control is pressed in my opinion..

Now if I select "Number" for the (rotate while pressed) value display, it works: The "text" changes as I turn the dial to reflect the value, but I would have expected this text to reflect the current value as soon as I press the dial.
I tried to tweak it with [(press){text:#@e_value#}] but it returns 0 before starting the rotation. and does not return to the primary value upon release.

I hope it's clear enough.
Not sure I caught everything but I think that probably a {text:p,...}  ... and a {title:p,...} action would solve the problem. They would be displayed upon pressing the dial and vanish (replaced by primary text and title) after the dial release. It would offer a consistent behavior with what happens for the value.

There is probably a workaround with intermediate text/title display variables but it is not very convenient.
Thanks for your help.

thx538 wrote:It defeats the principle of modularity between the editor and the script engine.

I don't know what is the principle of modularity between the editor and the script engine.
Could you explain this concept?
Thanks!

I want to postpone the design loading question to a later date; it will not happen now. It is not a must-have feature and doesn't add any new functionality to the plugin. I have so much to do and want to get this version ready for release. I need to focus on the important parts.

Hello again,

I have this script which is working well with rotate unpressed and released unpressed events as well as feedback from the DAW :

Code:

[(config){TriggerOnLocalMidiEvents:No}]
Set Design
[(init){minmax:1,8}{design:%trevligaspel%/Designs/CH_Navigator.xml}]
From DAW, Device chain: Get Length & Value
[(sysex:F0 6A XX F7){value:#VALUE(MID(@e_sysex,1,2))#}{@l_chnum:#VALUE(MID(@e_sysex,1,2))#}{text:#VALUE(MID(@e_sysex,1,2))#}{@g_max_ch:#MID(@e_sysex,4,2)#}] Arrives before device name
[(@g_dname_sel:*){title:#@g_dname_sel#}] Device Name

Rotate and release Unpressed
[(rotate:rn,1-8){value:#MIN(@e_value,VALUE(@g_max_ch)-1)#}{text:#@e_value#}{@l_chnum:#@e_value#}]
[(rotate:ln,1-8){text:#@e_value#}{@l_chnum:#@e_value#}]
[(release:n)(cc:16,0,1-24){sysex:F0 01 #@e_ccvalue# #@l_chnum# F7}] Will be enriched in BMT to clear browsing variables

Now if I add the following lines at the end of the script, in order to manage rotate pressed and release pressed events, as well as the corresponding feedback from the DAW :

Code:


From DAW, Variation: Get Length & Value
[(sysex:F0 6B XX F7){value:p,#VALUE(MID(@e_sysex,1,2))#}{minmax:p,1,#VALUE(MID(@e_sysex,4,2))#}{title:#CONCAT("Var. ",VALUE(MID(@e_sysex,1,2)))#}]

Rotate and release Pressed
[(rotate:p,1-8){@l_vnum:#@e_value#}{title:#CONCAT("Var. ",@e_value)#}{text:#@e_value#}]
[(release:r){cc:10,#@l_vnum#,127}]


... what happens is that executing a (not rotated) release event alternates between "pressed" and "unpressed" midi messages, I don't know why.

Log file from Bome Midi Translator with the first part (Release events):

Code:

1: MIDI IN [Bome MIDI Translator 4 Virtual In]: F0 01 11 02 F7
238: MIDI IN [Bome MIDI Translator 4 Virtual In]: F0 01 11 02 F7
242: MIDI IN [Bome MIDI Translator 4 Virtual In]: F0 01 11 02 F7
246: MIDI IN [Bome MIDI Translator 4 Virtual In]: F0 01 11 03 F7
483: MIDI IN [Bome MIDI Translator 4 Virtual In]: F0 01 11 01 F7
720: MIDI IN [Bome MIDI Translator 4 Virtual In]: F0 01 11 02 F7

Log file from Bome Midi Translator with the second part added (Alernate release events) although no pressed rotation took place. :

Code:

957: MIDI IN [Bome MIDI Translator 4 Virtual In]: B9 04 7F
963: MIDI IN [Bome MIDI Translator 4 Virtual In]: F0 01 11 04 F7
1200: MIDI IN [Bome MIDI Translator 4 Virtual In]: B9 04 7F
1206: MIDI IN [Bome MIDI Translator 4 Virtual In]: F0 01 11 02 F7
1443: MIDI IN [Bome MIDI Translator 4 Virtual In]: B9 04 7F

I can provide the midi plugin log file. It shows a release/rotated event (release:p) is fired while no rotation was made.

The midi plugin log file is here :
https://drive.google.com/file/d/1XB3zMvlQ3buJX55O-E5kPBcMcbQKEkOZ/view?usp=sharing

Edit: I will conduct additional test to make sure it's not a problem with the script.

thx538 wrote:Since we don't have a {text:p,...} action what is the intended effect if we select "Controlled by script" for the (rotate while pressed) value display ?

I admit that there's limited usage of "Controlled by script" for the (rotate while pressed). You can,e.g., have a script like this:

[(rotate:n){text:#@e_rotatevalue#}]
[(rotate:p){text:Pressed!}]

...just to show that you can display different things while you rotate the dial, depending on whether it's pressed.

The plugin has a single area for the value (targeted by the text action), so the text is replaced regardless of the pressed state. Due to this, I think the main (potential) use is with a Vpot or fader with title and value in the same position. With that configuration, the text is only visible while you rotate the dial so that different texts can be displayed, and when you release the dial, the title is displayed.

But to be honest, I think the other dropdown options for the (rotate while pressed) value are much more useful.

thx538 wrote:I have this script which is working well with rotate unpressed and released unpressed events as well as feedback from the DAW ...

The release events currently have no check for rotated/not rotated state, so they will toggle, as you have found. The press/release management is a bit shaky; I'll see if I can improve it.

Admin wrote:
The release events currently have no check for rotated/not rotated state, so they will toggle, as you have found. The press/release management is a bit shaky; I'll see if I can improve it.

Ah, thanks for the clarification, this was driving me crazy  
Now I can see in the documentation that we have (release:r) and (release:n) as distinct events, so should I wait for a correction or try to find a workaround, if any ... ?

This version fixes a number of script problems and have some tweaked font sizes.
The handling of release events is better, but I'm still struggling with it.

What is the expected behavior from the following script:

[(release:n){text:N 1}]
[(release:r){text:R 1}]
[(release:n){text:N 2}]
[(release:r){text:R 2}]

Should the plugin find the following command in the sequence that fulfills the r/n criteria regardless of which kind of release event was last triggered?
...or...
Should the plugin find the following command in the sequence that fulfills the r/n criteria after the previous command that fulfilled the same criteria?

Or put another way: should a sequence of release commands of a certain kind (say "n") be completely independent of release commands of the other kind?

Version 3.11.0.348

Thank you for this version.

• The release events are now properly triggered .. at least with my script above.
  
• The text/value display font on the fader is better now
  
• The text/integer issue seems to have been fixed as well.
  

The release events are working as expected

Admin wrote:
Or put another way: should a sequence of release commands of a certain kind (say "n") be completely independent of release commands of the other kind?

Of course yes ! In the context of interacting with the outside world, the press/rotate/release actions are meant to control a different parameter than the rotation without press.

I understand it is the way it behaves at the moment.