3.10.0.5 beta / 3.11 alpha

Admin wrote:I think we are talking about the same thing.
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.

Confirmed, we are talking about the same thing. 

 Fully agree with all you said in the last post. Everything is clear now. Thanks for the explanations.

I would like to suggest a new action for scripted faders and v-pots. The wish is to change the speed of faders and v-pots (fader speed/rotation speed).

This new action would allow to stop faders/v-pots when that control is disabled in the DAW, and also allow movement again when that control has been enabled in the DAW.

It would also allow to move the faders/v-pots faster or slower depending on custom variables.

The following example would set the speed of an v-pot to maximum, minimum, and half speed depending on the custom variable:

[(vpot:*) (@config:disable) {speed:0}]
[(vpot:*) (@config:bypass) {speed:100}]
[(vpot:*) (@config:volume) {speed:50}]

Yes, I've had some other requests for speed control (not script-related).

If the script controls the speed, it's the same "problem" as with the design (script vs editor), and I will probably have to solve it the same way.

I'll see if I can develop an intelligent solution that also works for non-scripted actions.

I don't have any stable updates yet, but here's a list of things in process:

I have added a {speed:...} action to set the fader and the vpot speed from the script.

When adding the speed action, I found it too complex to keep track of scripted properties that differ from editor properties. I have changed the scripted speed and design actions to change the editor's selected speed/design settings.

I need to redesign the dual button fader script management. Initially, I said the two fader buttons should have the same script, with only state icon settings as a potential difference. This was not a good design, and even if it looks OK when you use the faders, many unwanted things happen under the hood (e.g., duplicate midi commands). I will change to a principle similar to that for Vpots, i.e., the script for the lower button will be responsible for everything except (maybe) for the upper button state icon.

Or possibly I go the whole way and make the lower script responsible for everything, as for the Vpot. This would make the principles identical for scripted faders and vpots, and perhaps that's a good thing.

If the lower script should handle the upper button state icon, I need to redefine the icon action. Today, it is {icon:...}; maybe I'll change that to {icon1:...} and {icon2:...} where icon1 is for the lower button and icon2 for the upper (...and when moving to dials, icon1 is the left and icon2 is the right icon).

Thanks for the updated info!!

Everything sounds very good to me. I would vote for: 
- one script per single fader/vpot
- one script per synchronized fader/vpot

Regarding scripted faders, what do you think of this schema?:
{icon:…} -> sets the icon of single fader and sets the icon of lower synchronized fader
{uppericon:…} -> sets the icon of upper synchronized fader. If this action is in the code of a single fader, it is ignored

Another item that can be different is the "Value Display". Now we can set "controlled by script" in the lower and upper fader. Could be an option to use the same schema of icons:
{text:…} -> sets the text of single fader and sets the text of lower synchronized fader
{uppertext:…} -> sets the text of upper synchronized fader. If this action is in the code of a single fader, it is ignored

My idea with neutral names was that the same names could be used for dial scripts.

But you are correct about the upper text, I had forgotten about that.  When I take the texts into account, your suggestion is much better than mine.

I have discovered an issue. When changing pages the Fader Script Button values reset while the Mackie Control Button values don't

I'm making significant changes to the scripted buttons at the moment, so please relax the tests a bit until the "new" version is ready.

OK, this version seems to be reasonably stable.

I have made significant changes to the script functions to make the internal flow more logical. In addition:

• The scripted faders now work as the scripted vpots, i.e., the script for the lower button controls both buttons.
  
• There is now a {textupper:...} action to control the text for the upper button for faders and vpots.
  
• There is now an {iconupper:...} action to control the state icon for the upper button for faders.
  
• There is now a {speed:...} action to control the speed for faders and vpots.
  

Version 3.10.0.464

I made an SD XL test with 32 scripted faders displaying the VU meter.

The performance is beyond bad; I need to look at that.

I am on version 3.10.0.464

Black dB fader design seems to be not well configured, as icons are below the meters of this design. Here you can see the difference between Black dB and Blue designs showing the same icon:



   

Weird behaviour with the script file selection. This lower fader button is changing the script path automatically pointing to an old script file that currently doesn't exist:



I have removed the button and I have configured a new button from the scratch in the same position. I select an existing script file, and later, it changes automatically to the old unexisting file.

Restarting SD+ has fixed the issue.

Synchonized faders/vpots controlled by an script that contains {design} actions are showing the drop-down menu of designs instead of showing the message "Controlled by script".

Currently the Midi plugin is combining two synchronized scripted faders/vpots by proximity, detecting if two buttons are contiguous up/down or left/right.

What about to change that and combine them by user selection and not proximity?

In the upper button, instead the sentence "Please use the lower button for script definition", we could have a drop-down menu with the names of existing script files of lower buttons with a label like "Select the lower button you want to link this upper button"

It would be useful to have a trash icon next to the script file selection to remove the script file.

I am experiencing a lot of times that the text defined in (init){textupper:…} is displayed in the lower button of combined faders.

Refreshing the button changing the page of SD back and forth fixes the issue.

jordikt wrote:Black dB fader design seems to be not well configured.

Oh, I render the things in the wrong order. Nicely spotted.

jordikt wrote:Weird behaviour with the script file selection. This lower fader button is changing the script path automatically pointing to an old script file that currently doesn't exist

Script settings shouldn't be synchronized between buttons, I'll check that.

jordikt wrote:Synchonized faders/vpots controlled by an script that contains {design} actions are showing the drop-down menu of designs instead of showing the message "Controlled by script".

Yes, I mentioned this a while ago. I no longer keep separate settings for the script and the editor. The script is changing the setting in the editor so there is no longer any confusion when you change it manually. The selected design will be changed when you change it in the editor and when the script is changing it. Do you still think it should be hidden (or maybe have the "controlled by script" message along with the dropdown?). The same thing, btw, is true for the speed, it can also be changed both from the script and manually.

jordikt wrote:In the upper button, instead the sentence "Please use the lower button for script definition", we could have a drop-down menu with the names of existing script files of lower buttons with a label like "Select the lower button you want to link this upper button"

What would be the difference besides the very odd fact that you may link two buttons that are not adjacent?

jordikt wrote:It would be useful to have a trash icon next to the script file selection to remove the script file.

I have never seen any use for such a function. If you say you want to use a script file, you need a file reference; if you select not to use a script file, the file reference is (or should be) ignored. It makes no sense to me to say you want a script file and then remove the file reference. I think your request comes from the bug where script references were synchronized between buttons, which they should not be.

jordikt wrote:I am experiencing a lot of times that the text defined in (init){textupper:…} is displayed in the lower button of combined faders.

Refreshing the button changing the page of SD back and forth fixes the issue.

Interesting, that shouldn't be the case, I'll check that.

jordikt wrote:Black dB fader design seems to be not well configured.

Fixed.

jordikt wrote:Weird behaviour with the script file selection. This lower fader button is changing the script path automatically pointing to an old script file that currently doesn't exist

Script settings aren't synchronized. I can't reproduce this problem, and I get the impression it's a Stream Deck bug rather than a plugin bug. You say you deleted the button and recreated it in the same place. It should be impossible for the "new" instance of the plugin to know about values from the previous instance, but I have sometimes seen that new instances that replace old instances of the same type sometimes inherit settings in some mysterious way. It is impossible for the plugin to do something like that, so it must be a Stream Deck problem.

jordikt wrote:I am experiencing a lot of times that the text defined in (init){textupper:…} is displayed in the lower button of combined faders.

Refreshing the button changing the page of SD back and forth fixes the issue.

Fixed.

In addition,  the script performance when showing VU is dramatically enhanced.

Version 3.10.0.479

It seems to me that this last version has something wrong or corrupt.

Since yesterday that I installed this new version, I am experiencing this message very often:



As example, today I did these steps:

- I have restarted my macboook
- Without running any DAW (no midi messages sent to/from SD), I get this message
- I quit the SD editor, and disconnect SD USB cable
- I connect it again, opening the editor
- The midi plugin buttons are shown correctly
- I create a new page
- I create a new button dropping the Generic Midi icon to the button
- Any DAW is running, but I get the same message saying that Midi Plugin is loading

I have never experienced this issue before. Yesterday I had this issue 2 or 3 times, but I thought it was due DAW midi messages, but today it seems that the problem is not the midi messages.


EDIT: This is reported with version 3.10.0.464. I will download the 3.10.0.479 and see it I am still experiencing this issue.

If you get this problem again, please check if the log file says anything about the reason.

Yes, I am experiencing it right now again with the last version.

I suppose I have to restart the system and activate the logging, isn't it?

Or do I have a log file currently that I can send you?

I have sent you the log file by email. It is the log file before activating the extended log, that I will activate now after restarting the SD+

EDIT: I have pressed these buttons 30 minutes later, and they work fine now. I cannot replicate this issue anymore. 

The upper text seems to work better than before, but I am experiencing another weird issue.

In this video you can see that when I press the upper button the upper button shows values instead the correct text. Pressing the lower button shows correctly the lower and upper texts.

The code of these combined faders with white fields is the following one:

[(init) {value:#@value_1st_fader#} {text:#@value_1st_fader#} {textupper:1st Fader} {speed:100}]

[(cc:1,39,*) {value:#@e_ccvalue#} {text:#@e_ccvalue#} {@value_1st_fader::#@e_ccvalue#}]

[(fader:*) {cc:1,39,#@e_fadervalue#}]

[(cc:1,39,127)   {iconupper:%trevligaspel%/SideShowFx/Icons/Cubase-Icon2.png}]
[(cc:1,39,<126<) {iconupper:#none#}]

[(cc:1,39,0)   {icon:%trevligaspel%/SideShowFx/Icons/Cubase-Icon2.png}]
[(cc:1,39,>1>) {icon:#none#}]

[(cc:11,127,*) {vu:#@e_ccvalue#}]


=====

You can see also two combined faders with red fields in the video. These faders works perfectly, using an script that it is the same than the previous one, but without design actions:

[(init) {value:#@value_1st_fader#} {text:#@value_1st_fader#} {textupper:1st Fader} {speed:100}]

[(cc:1,39,*) {value:#@e_ccvalue#} {text:#@e_ccvalue#} {@value_1st_fader::#@e_ccvalue#}]

[(fader:*) {cc:1,39,#@e_fadervalue#}]

[(cc:1,39,127)   {iconupper:%trevligaspel%/SideShowFx/Icons/Cubase-Icon2.png}]
[(cc:1,39,<126<) {iconupper:#none#}]

[(cc:1,39,0)   {icon:%trevligaspel%/SideShowFx/Icons/Cubase-Icon2.png}]
[(cc:1,39,>1>) {icon:#none#}]

[(cc:11,127,*) {vu:#@e_ccvalue#}]


So maybe the bug has relation in some way with the design changes.

EDIT: I have pressed these buttons 30 minutes later, and they work fine now. I cannot replicate this issue anymore. 

Script changes of speed work fine except if you want to change the speed depending of the position of the fader.

Using this code, speed changes in the UI, but the change is not executed until the pressed button is released:

[(init) {value:#@value_3rd_fader#} {text:#@value_3rd_fader#} {textupper:3rd Fader}]
[(cc:1,39,*) {value:#@e_ccvalue#} {text:#@e_ccvalue#} {@value_3rd_fader::#@e_ccvalue#}]
[(fader:*) {cc:1,39,#@e_fadervalue#}]
[(cc:1,39,20-40) {speed:100}]
[(cc:1,39,40-60) {speed:80}]
[(cc:1,39,60-80) {speed:60}]
[(cc:1,39,80-100) {speed:40}]
[(cc:1,39,100-127) {speed:20}]

You can see this behavioour here:
https://youtu.be/QPbzAzYqJyU

===

If you change the last lines to specific values, speed changes are not executed but also not shown in the UI:
[(cc:1,39,20) {speed:100}]
[(cc:1,39,40) {speed:80}]
[(cc:1,39,60) {speed:60}]
[(cc:1,39,80) {speed:40}]
[(cc:1,39,100) {speed:20}]

The handle of the scripted faders are over the icons if both items are in the same position.

Is it by design?

I think the icons should have the priority over the handle visibility. Here a Cubase icon is hidden by the four handles: