3.10.0.5 beta / 3.11 alpha

Not quite sure whether this has already been adressed. But the button value display isn't always fully resetet when changing between button types ... e.g. vpot or scrub wheel and script

Admin wrote:

jordikt wrote:The only issue I see is that the VU of the track in Cubase and the representation of the VU in the Midi Plugin don't match. The VU of the Midi Plugin is lower than the DAW VU.

Yes, I have noticed the same thing. It must be how Cubase handles the output. If I drive the volume to max, I get a max response in the VU meter, so the plugin receives the complete value range (so it isn't a problem where the plugin has scaled down the VU range).

I guess Cubase treats the VU the same as the volume fader. The raw midi value is not based on the visual position but rather on the dB value. The only way to solve that is to implement a new type of dB file where the received midi value can be translated to a visual percentage.

I have setup a MC and a new script GM button. Looks to me, like the plugin scales the VU meters differently. 

Is there a reason that the "Generic 100%" value display is excluded from the MC pulldown menue?

I was only able to load a diy "Fader design" when I copied the folder into 

"...\AppData\Roaming\Elgato\StreamDeck\Plugins\se.trevligaspel.midi.sdPlugin\Images\FaderSets\Buttons\Rode"

Loading the Fader.xml using another path failed.

Admin wrote:

jordikt wrote:The logic of new scripting events, actions and variables for scripted faders and vpots is a little bit complex to me. I have got an idea to make it easier and more flexible.

Besides breaking all the syntax rules, such a syntax would be a nightmare to implement. Your syntax means that actions would also be events, and some commands with multiple actions must internally be converted to multiple commands. I find that very complex.

The current syntax follows the same rules as everything else. When you press the button, you get an event where you can send midi commands, and when you receive a midi command, you can adapt the display to the received value. What in this do you find complex?

I'm not sure to understand what syntax rules is my proposal breaking. Maybe you mean that {cc:1,1,link} is breaking the rule that the 3rd value must be a number. You can change the code to {linktocc:1,1,*} to do the same action and respect the syntax rules.

I don't see that this syntax means that actions are also events. The events are (press) and (release) and the action is just to link the fader/vpot to a midi channel and a midi cc/pb/note/pc/cp number.

Regarding the complexity of the current scripting, you also said that the logic is complex. I just tried to propose an idea to make it easier.

You can forget the syntax of my proposal. Just think if it is a good idea to create a syntax to link the fader/vpot to a midi message, so the Midi Plugin would do itself the updating of the fader/vpot representation to the midi value.

If the idea of the link concept is a bad idea, let's stick to the current syntax! 

Admin wrote:

jordikt wrote:There is a minor issue when scripted vpots and non-scripted vpots are set to both ways that I never reported before. When I press twice to change the direction, sometimes the midi value changes, sometimes the midi value keeps at the current value. It could be possible to fix it?

The direction change is a bit tricky. Right now, the direction switch isn't done at all for scripted vpots, so I need to fix that.

For non-scripted vpots, the plugin, at the first button press, sends the midi command. At the second button press, it switches direction if appropriate, then sends the midi command. If you experience that it sometimes changes the value and sometimes not, it must be a millisecond timing issue where you release the button exactly between the "change direction" action and the "send midi command" actions in the plugin, in which case the sending of the command is stopped.

I could maybe lock that sequence so the second command is always sent. A quick double press would send a midi command with an increased or decreased value, followed by a command to restore the previous value. Any other solution would mean that I must wait with the first command until I know it isn't a direction switch double press, which would be confusing.

I agree that the small variations of the double press for direction change are complex to solve.

IMHO, the best option is to do nothing and leave it as it works now, or give the user two options to change the behaviour:

- a first checkbox to enable/disable "Wait for double press time" 
- a second checkbox to enable/disable "Don't move after double press" 

If the first checkbox is enabled, the vpot would start to move after the time defined for "Direction Switch Timing"

If the second checkbox is enabled, the vpot will only change the direction after a double press. With this configuration enabled, one press moves the vpot and double press just change its direction.

If them were available, I would configure all my vpot buttons enabling both checkboxes.

Just to give you my user experience: All my vpots are configured with a double press of 800 miliseconds. Even this timing is high, the performance is not so efficient as I would like.

A lot of times I press twice and the vpot doesn't change the direction, but it rotates in the "wrong" direction a little bit more.

So I always press twice and release the button to look to the display and see if the direction has changed correctly. After that, I press the button to rotate the vpot.

Admin wrote:

jordikt wrote:IMHO, the best option is to do nothing and leave it as it works now, or give the user two options to change the behaviour:

- a first checkbox to enable/disable "Wait for double press time" 
- a second checkbox to enable/disable "Don't move after double press" 

Yes I agree it's the only way to fully solve the issue. I'm not sure about the second checkbox; why do you see a need for that?

It makes sense to me to have the option to not rotate the vpot when the vpot changes the direction. 
In other words, it's a configuration that wouldn't mix two different actions (rotate and change direction) if the user wants it.

Admin wrote:Using speed=0 isn't a bad idea, after all.

But I still think it should be solved with a script. What I can do is ensure that the fader doesn't move if speed=0 when using a scripted fader.

As far as I understand the current status of the fader scripts, these scripts only allow to change fader or vpot volume? When I am using just a single button it still would be nice to deactivate chanign the volume by pressing the button. The question is, does the new script design still allow to change the value of the volume by receiving a midi volume message?

Could you post some code as example of how to set the speed value 0?

It would be nice being able to choose the color of the text displayed in the "info aera" not only the color of the "info aera" itself.

Admin wrote:

• For scripted faders and Vpots, a speed value 0 means that the script event (fader/vpot) will be triggered once. Speed values above 0 mean that events will be triggered repeatedly.
  
• The VU meter has a new dropdown for "scale". If the control you connect to has a linear behavior, select "None" in the dropdown. If the control has a non-linear behavior (like the "Meter All" function in Cubase), select the appropriate daw in the dropdown. The VU scaling is an addition to the dB files, and the dropdown only shows dB files that have VU scaling defined. Currently, this is only the Cubase 6dB file.
  

- Could you explain how to move the vpot after pressing the button when speed value is set to zero? Could you post some code as example?

- VU meter scale is not available in scripted fader, only in non-scripted fader. It works very good in Cubase, except for lower values than cc=20, where VU is not shown.

Here is a video showing the VU when the fader is near to -oo:

https://youtu.be/d-edHwDGy9E

The change of design is very powerful. 

I am using this code with a scripted vpot to change the design:

[(init){value:#@value_1st_vpot#}{text:#@value_1st_vpot#}]

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

[(cc:1,39,127){text:MAX}{design:%trevligaspel%/My VPot/VpotOrangeRing/VpotOrangeRing.xml}]
[(cc:1,39,0){text:MIN}{design:%trevligaspel%/My VPot/VpotRedRing/VpotRedRing.xml}]

Issue 1:
When I press the button to decrease the vpot value, the vpot stops when it arrives to cc:1,39,1
When I press the button to increase the vpot value, the vpot stops when it arrives to cc:1,39,126
So the vpot stops one value before doing the change of design. Pressing again the button, the vpot moves to 0 or to 127 and the design changes accordingly.
If the vpot decreases the value from 126 to 0 with the red design loaded, it doesn't stop at 1 and arrives to 0.
If the vpot increases the value from 1 to 127 with the orange design loaded, it doesn't stop at 126 and arrives to 127.

Issue 2:
If the design to change is a custom design that is not visible in the drop-down menu, the button changes to a big white square. IMO it would be necessary to add the custom design to the dropdown menu in the case it is not listed there, and also loading the design correctly in the vpot button.

The new configuration for changing the rotate direction of the vpots works very well.

I have set the double press time to 300 ms, enabling both checkboxes. It works like a charm.

Admin wrote:

Joerg wrote:It would be nice being able to choose the color of the text displayed in the "info aera" not only the color of the "info aera" itself.

You do that with the built-in text property popup in the editor. The fader design has a default configuration for colors, text size and font, but you can change everything in the editor. If you leave the font size at the default setting (12 pt), it is dynamic (the font is scaled down if the text doesn't fit); if you change it, it will be locked to the size you select.

Well, looks like this works as long as you don't try to set the textcolor to white #ffffff  . 

Good morning,
Sorry for this stupid question.
I would happily help testing this new version but I am not sure I understood everything.

• Does the new scripting applies to dials (I have a streamdeck+) ?
  
• Is there a summary of the new scripting capabilities (for dials) ?