Re: 3.10.0.5 beta / 3.11 alpha

by Joerg Sun Jun 02, 2024 11:20 am

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

by Joerg Sun Jun 02, 2024 2:35 pm

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.

by Joerg Sun Jun 02, 2024 3:39 pm

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

by Joerg Sun Jun 02, 2024 3:47 pm

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.

by **Admin** Sun Jun 02, 2024 4:35 pm

The plugin doesn't scale the VU in any way, but you are using two very different "systems" with those two buttons.

The MC button uses the Mackie Control protocol, a "standard" protocol upon which Steinberg has no influence. The MC VU level is reported in 12 steps and is, for all I can tell, linear.

The Generic button uses the Midi Remote, which is Steinberg proprietary, and they can do whatever they like. The VU level is reported in 128 steps, and it looks to me that they use a similar "dB curve" for the VU level as they do for the dB display. The plugin receives values 0-127, translates this to a percentage 0-100% and uses that for the VU level. There isn't much more I can do unless we introduce a new type of translation file.

I'll check the "Generic 100%" dropdown.

And I'll check the fader design issue as well. It looks as if the plugin isn't notified when you select an xml file, which is very odd.

And I'll examine the code for text management at button type change. I thought I had taken care of that but obviously something isn't right.

by jordikt Sun Jun 02, 2024 5:13 pm

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! Very Happy

by jordikt Sun Jun 02, 2024 5:46 pm

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.

by **Admin** Sun Jun 02, 2024 7:09 pm

jordikt wrote: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.

The script engine is event-driven. When it is notified that something has happened, it checks whether the script has any events for that thing, e.g. (press). If it has, it executes the actions for that event. This is the script engine's fundamental operation procedure regardless of what events it receives.

In your example, you have a command like this: [(press){cc:1,1,link}]

When the script engine receives a press event, it checks if the script has any (press) events defined and, if so, runs them. When the script engine receives a fader event, it checks if the script has any (fader) events defined and, if so, runs them.

There are no (fader) or (cc) events in your design. Instead, you have actions with a link parameter that, in effect, must become dynamic event definitions for a (fader) event and a (cc) event; otherwise, the script engine fails to find anything to do when it receives a fader or cc event.

I'm not saying that the link idea is bad; I'm just saying that it breaks the current script rules, and I must make significant changes to the script parser and the script engine if I implement it.

by **Admin** Sun Jun 02, 2024 7:17 pm

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?

by jordikt Sun Jun 02, 2024 10:58 pm

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.

by Joerg Sun Jun 02, 2024 11:10 pm

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?

by **Admin** Mon Jun 03, 2024 4:55 pm

I've fixed several bugs.
The Latch button should be operational now.
There is a new script action {design:_path to design xml file_} with which you can dynamically change the design for VPots and faders.
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.

Version 3.10.0.327

by jordikt Mon Jun 03, 2024 5:00 pm

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

by **Admin** Mon Jun 03, 2024 5:00 pm

Joerg wrote:The question is, does the new script design still allow to change the value of the volume by receiving a midi volume message?

Yes, of course. These commands will "link" the fader to a CC:

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

by **Admin** Mon Jun 03, 2024 5:01 pm

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

That's not code; you draw the speed slider to 0.

by Joerg Mon Jun 03, 2024 10:08 pm

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.

3.10.0.5 beta / 3.11 alpha - Page 3 Screen29

by **Admin** Mon Jun 03, 2024 11:55 pm

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.

by jordikt Tue Jun 04, 2024 1:03 am

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

by jordikt Tue Jun 04, 2024 2:30 am

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.

by jordikt Tue Jun 04, 2024 2:33 am

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.

by Joerg Tue Jun 04, 2024 7:41 am

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 What a Face

.

by **Admin** Tue Jun 04, 2024 8:28 am

jordikt wrote:
- 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.

The vpot is moved with the {value:} action. I don't know what code to show, but say you want to move the vpot one step up; you do like this:

[(vpot:*){value:#@e_vpotvalue + 1#}]

My initial thought was that you control VU yourself with the script, so the scale isn't necessary, but having the scale available as well is a good idea.

For some mysterious reason, the VU output from Cubase uses a curve like this:

3.10.0.5 beta / 3.11 alpha - Page 3 Curve

3.10.0.5 beta / 3.11 alpha - Page 3 Curve

Cubase doesn't output anything other than "0" until the level is above 20% (visually) on the scale, so I can do nothing to visualize the low levels better.

by **Admin** Tue Jun 04, 2024 8:46 am

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

I agree that this can be confusing, but I don't know how to solve it better (other than altogether skipping the text property popup and having everything in the plugin area).

The design has settings for color, font and size. I use the design setting as long as the settings in the text property popup are the default settings for each property. The default text properties are size=12pt, color=white, font=Default (=Tahoma,bold)

As long as the size is 12pt, I use the size from the design.
As long as the color is white, I use the color from the design.
As long as the font is Default, I use the font from the design.

So when you want a white color, you need to set it to #FFFFFE or something similar since setting it to #FFFFFF will cause the plugin to use the design color.

by thx538 Tue Jun 04, 2024 9:20 am

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) ?

by **Admin** Tue Jun 04, 2024 9:26 am

thx538 wrote: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) ?

Good morning.

The current alpha version only includes the new Generic Midi button, and the new scripting capabilities apply only to that button. Dial scripting will come in a later release.

by Sponsored content