Scripted dial alpha

I realized there was a problem accessing dropdown items from a script if the dropdown hadn't been displayed in the editor. The dropdown content wasn't created until it was displayed, so if a script tried to set a value for the dropdown, it failed. I think this was the reason you have seen different behaviors. This is fixed now.

All dropdowns have numbered items. In the script, you can reference...

• the number,  {design:1}
  
• the name, including the number (as displayed)  {design:1. Blue}
  
• the name excluding the number {design:Blue}
  

The action {titlevalueposition} is added.

The editor is updated after script changes to ensure the correct set of fields.

Version 3.11.0.264

I'm sorry, but any of my dropdown menus has numbered items. I have restarted SD+ and computer... 
Maybe is due to macos?

How odd, the macOS part should have been updated.
I made a new build and verified that macOS has also been updated.

Version 3.11.0.265

Admin wrote:
Sorry, I don't get it.
...
The value that triggers the command is, of course, the new target value.

That's what I did not realize in the first place, sorry.

Admin wrote:
So, exactly what is the problem?

No problem indeed, I was trying to avoid triggering the rotate action when the value (Before rotating)  is already at the min or at the max, which is not done natively by the plugin.

So for the record, with {minmax:1,24} I ended up with the following command :

[(rotate:r,1-24)(@g_trsc:0)(cc:16,0,1-23){cc:16,0,#@e_value#}]  
[(rotate:l,1-24)(@g_trsc:0)(cc:16,0,2-24){cc:16,0,#@e_value#}]

... where CC16,0,* is sent/returned by the daw when the track selection changes, which can happen outside of the streamdeck.

Thank you for your patience

Admin wrote:Version 3.11.0.265

This version shows the numbered menus correctly.

I have tested all the numbers of all the menus and everyone works perfectly.

But an issue can occur in the Fader/V-pot display if a command is executed with a higher number than the highest one of the menu.

As example, this occurs if a command {design:7} is executed for v-pot:



The same issue occurs if the command {design:15} is executed when fader is selected:



This problem only occurs with {design}. The other actions works correctly.

---

Another problem that can occur is that different custom designs take the same number, depending on the order that custom designs are loaded by the plugin.

As example, here you can see that the reference number 101 is assigned to two different custom designs:

 

The same problem can happen with custom dB files.

I think it's better that custom designs and custom dB files are only called by the whole name, and use the index number only for the factory items of the menus.

---

The index number for Volume and Pan bar in the Rotate dial section doesn't match with the same displays in the Rotate while pressed section:

Rotate dial section: Volume bar=3 / Pan bar=4
Rotate while pressed: Volume bar=2 / Pan bar=3

Maybe it's not possible, but a solution is to move the V-pot item to the end of the Rotate dial menu. Then we would have:

Rotate dial section: Fader=1 / Volume bar=2 / Pan bar=3 / V-pot=4
Rotate while pressed: None=1 / Volume bar=2 / Pan bar=3

---

The {titlevalueposition} action doesn't match with the editor label that is written in plural ("Title/Value positions"). I think it would be better that both are in singular.

---

There is a bug with the text colors of the Volume bar and Pan bar. The color selected in the "Value text" is used for the value and the title, but the color selected for the "Title text" is ignored.

thx538 wrote: I was trying to avoid triggering the rotate action when the value (Before rotating)  is already at the min or at the max, which is not done natively by the plugin.

That's a bug, I'll fix that.

jordikt wrote:But an issue can occur in the Fader/V-pot display if a command is executed with a higher number than the highest one of the menu.

I think this is a matter of opinion. The design dropdown has always worked like that; if you try to set a design it can't find, it displays the sought-after name together with (Not found). Is your opinion that if it can't find a design accessed with a number, it shouldn't show this?

jordikt wrote:Another problem that can occur is that different custom designs take the same number, depending on the order that custom designs are loaded by the plugin.

This is also a matter of opinion, I think. I was aware of this issue when I implemented the automatic numbering, but I can't see this as a problem.
An individual user will probably have a pretty stable environment, so situations where numbers suddenly refer to a different object would be rare. And if the user makes such a change, he's aware of it, so it can't come as a surprise. If anyone wants to avoid such a problem, he can always reference the object by name, which I will stress in the documentation.
Another consequence for me is that I cannot change the numbering of the existing built-in designs or dB files. If I add anything, I must add it at the end and break the alphabetic sorting of the list.

jordikt wrote:The index number for Volume and Pan bar in the Rotate dial section doesn't match with the same displays in the Rotate while pressed section

Good point, but I think I'll move both the bar items to the top in both lists.

jordikt wrote:The {titlevalueposition} action doesn't match with the editor label that is written in plural ("Title/Value positions"). I think it would be better that both are in singular.

Done.

jordikt wrote:
There is a bug with the text colors of the Volume bar and Pan bar. The color selected in the "Value text" is used for the value and the title, but the color selected for the "Title text" is ignored.

Fixed.

Admin wrote:

jordikt wrote:But an issue can occur in the Fader/V-pot display if a command is executed with a higher number than the highest one of the menu.

it displays the sought-after name together with (Not found). Is your opinion that if it can't find a design accessed with a number, it shouldn't show this?

I think it is very useful to show "(Not found)" as it is now. I wasn't aware of this behaviour.

Admin wrote:

Another problem that can occur is that different custom designs take the same number, depending on the order that custom designs are loaded by the plugin.

An individual user will probably have a pretty stable environment, so situations where numbers suddenly refer to a different object would be rare. And if the user makes such a change, he's aware of it, so it can't come as a surprise. If anyone wants to avoid such a problem, he can always reference the object by name, which I will stress in the documentation.

The current "risk" is that the plugin loads a custom design in the drop-down menu only when this custom design is shown in the SD+ screen.
The only difference in the two screenshots I posted with the number 101, is that in the first one I started the session in SD+ with Cubase Faders page and in the following session I started with Cubase Panoramas page.
That's why I see a risk to numbering dynamically the custom designs. I think users can give a good/short name to their designs, and numbers can be avoid.
Anyway, if you stress it in the documentation, it should not be a big problem.

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.

Admin wrote:Another consequence for me is that I cannot change the numbering of the existing built-in designs or dB files. If I add anything, I must add it at the end and break the alphabetic sorting of the list.

I wouldn't care of the alphabetic sorting. I think the most part of users don't know that. I have to confess that I never noticed that menu items are sorted...

IMHO, the only important thing is that the index numbers never change along the time: if "Logic" is 106 today, it should must keep the 106 index always and forever.

As example, this is my dropdown menu of dB value:



I only have one custom file that is *TotalmixFX with the index 109. I think the custom dB files should be listed separated in this menu as the custom designs list. Why? Because if I add a new dB file called "*ABC" the three items I use (Live, Cubase, Totalmix) will be renumbered and all my scripts will select incorrect db files.

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:IMHO, the only important thing is that the index numbers never change along the time: if "Logic" is 106 today, it should must keep the 106 index always and forever.

Exactly.

jordikt wrote:I only have one custom file that is *TotalmixFX with the index 109. I think the custom dB files should be listed separated in this menu as the custom designs list. Why? Because if I add a new dB file called "*ABC" the three items I use (Live, Cubase, Totalmix) will be renumbered and all my scripts will select incorrect db files.

Yes. As with the designs, I must keep the existing dB file numbering unchanged. Keeping custom designs separate is a good idea.

Admin 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.

Excellent information, thanks.

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

thx538 wrote:

Admin 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.

Excellent information, thanks.

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

Interesting. The first time I tried the #e_tics# I also get a maximum values of -20 and +22. Then I wrote a post saying that the maximum values were -20 and +22, but they are very extreme, and I considered that +14 and -14 were the "adequate" values to do agressive automations/transitions.

But after restarting the SD+ and the computer due some inconsistences of the plugin, I only get a maximum values of -12 and +12, and I considered that +6 and -6 were the "adequate" values to do agressive automations/transitions.

I edited the post to these last values at the same time that  @Admin replied using the not edited text of the post. So there were some confusion here...

I will test the tic values again when I get home.

@thx538 , did you tested this values with the last beta version?

@Admin , could you do the test also to see what values do you get?

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.

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.

I have thought an approach that maybe could help to load custom designs at starting, with the option of assigning an index or keyword to use in the scripts.

The idea is that the plugin could save a small database/list of custom designs and its path using the "Global Settings".

What do you think of having a new tab where we could have three cells: 

- one cell for typing/browse the path of the custom design

- one cell (not editable) where we would see the name of the design that will be shown in the drop-down menus after the path has been entered

- one cell where we could enter a index/keyword to use in the scripts. For avoid problems with in-built index, we could force this index to be alphanumeric (at least one letter)

And we could have three drop-down areas in this new tab:

- one for Fader designs
- one for V-pot designs
- one for dB files

The dB files list would be useful to enter an index/keyword to use in scripts.

jordikt wrote:The idea is that the plugin could save a small database/list of custom designs and its path using the "Global Settings"...

I believe this is a very complex solution to a specific problem that very few users will have. The numbering was introduced to simplify things, not make them more complex. If the numbering of the custom objects causes a problem, I think the simplest solution is to remove it altogether (from custom objects).

You can always use the name or path in the script. If you don't want to specify a path every time, you can create a background script that puts the path in a global variable and reference that variable in the scripts.

I'm actually starting to think it was a mistake to introduce the numbers; it makes the implementation more complex, it's cumbersome to explain (especially for custom objects), and it adds no functionality other than that you can save a couple of characters in the script.

Admin wrote:I'm actually starting to think it was a mistake to introduce the numbers; it makes the implementation more complex, it's cumbersome to explain (especially for custom objects), and it adds no functionality other than that you can save a couple of characters in the script.

I agree

And just a detail ... I read in the documentation : "The "new" script engine is used by the scripted dial and the Generic Midi button, but NOT by the Script button."
I thought the new script engine was now used for legacy scripted buttons. Am I Correct ?

It would be possible to select an item from a drop-down menu (as example "Cubase/Nuendo, 6dB"), click a label or a button in the editor to copy the item name to the clipboard, and then go to the script to paste the item name?

thx538 wrote:And just a detail ... I read in the documentation : "The "new" script engine is used by the scripted dial and the Generic Midi button, but NOT by the Script button."
I thought the new script engine was now used for legacy scripted buttons. Am I Correct ?

Correct, I have removed that comment now.

jordikt wrote:It would be possible to select an item from a drop-down menu (as example "Cubase/Nuendo, 6dB"), click a label or a button in the editor to copy the item name to the clipboard, and then go to the script to paste the item name?

You do anything to avoid typing some characters, don't you?

It is possible, at least on Windows. I don't know if macOS requires some special rights to allow that. The downside is that I must litter the editor with "copy buttons", and again, all just to avoid typing some characters.

I agree it would be a nice feature if it were easily implemented without rearranging the complete editor design. I'll check if I can trap a right-click to copy the name to the clipboard,

Admin wrote:

jordikt wrote:It would be possible to select an item from a drop-down menu (as example "Cubase/Nuendo, 6dB"), click a label or a button in the editor to copy the item name to the clipboard, and then go to the script to paste the item name?

You do anything to avoid typing some characters, don't you?

It is possible, at least on Windows. I don't know if macOS requires some special rights to allow that. The downside is that I must litter the editor with "copy buttons", and again, all just to avoid typing some characters.

I agree it would be a nice feature if it were easily implemented without rearranging the complete editor design. I'll check if I can trap a right-click to copy the name to the clipboard,

I am a lazy typer, that's true...

But seriously, my goal is not to avoid typing some characters.

I think that typing "Fader", "V-pot" or "Pan bar" for the display is perfect. And I think it's more convenient than writting numbers, because names give more clear information if you want to edit the code after a long time.

But in other menus there are several things that make easy to type mistakes:

- long sentences
- some words/letters in Caps at the middle of the sentence
- characters like "/" or "-" or ","
- double spaces

Probably the best option would be to copy/paste. User can copy the item clicking the label of the drop-down menu as it is now. As example, clicking "Value display", we could copy the menu item selected in the value display:

  

If the copy/paste solution is not implemented, I would keep the numbering (but only for built-in items). The numbering of built-in items is better than nothing, IMHO.

I can capture the right mouse click and make a copy to the clipboard. Currently, there's no visual feedback saying "copied to clipboard"; I'll see if I can add that later.

With that, I will remove all numbering, including for built-in items. It's awkward to handle in code and puts additional complexity when I add items in the future.

Admin wrote:

jordikt wrote:The idea is that the plugin could save a small database/list of custom designs and its path using the "Global Settings"...

I believe this is a very complex solution to a specific problem that very few users will have. The numbering was introduced to simplify things, not make them more complex. If the numbering of the custom objects causes a problem, I think the simplest solution is to remove it altogether (from custom objects).

You can always use the name or path in the script. If you don't want to specify a path every time, you can create a background script that puts the path in a global variable and reference that variable in the scripts.

I'm actually starting to think it was a mistake to introduce the numbers; it makes the implementation more complex, it's cumbersome to explain (especially for custom objects), and it adds no functionality other than that you can save a couple of characters in the script.

If it's a complex solution, kill it!! 

But the main goal of this idea was not to have a cell to insert an index/keyword for custom designs. That was an additional feature that I thought it could be helpful.

The main goal of the idea was: start SD editor from scratch, click the drop-down menu of designs and see all the custom designs in the list, just like we have the custom value files.

Maybe a database/list of custom designs could be created under the hood after user clicks the button "Add design"?

Admin wrote:I can capture the right mouse click and make a copy to the clipboard. Currently, there's no visual feedback saying "copied to clipboard"; I'll see if I can add that later.

With that, I will remove all numbering, including for built-in items. It's awkward to handle in code and puts additional complexity when I add items in the future.

Wow, great !!

Following my-custom-design-menu-items-obsession...

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?

jordikt wrote:Following my-custom-design-menu-items-obsession...

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#}
  

???