3.10.0.5 beta / 3.11 alpha

Hmm, would be possible to overload a fader event?

Example:
A "fader" event is set to ch 1 cc 1 and reacts to changing the value from outside.
The VU is set to ch 1 cc 10 

Now I would like to overload the fader with a press event setting ch 1 cc 5 127 (e.g. mute/un-mute)

I don't know if I fully understand you, but if you set the fader speed to 0, you will get a single (fader) event every time you press the button without having the fader move (in effect, a (press) event).

With a (fader:*) event, you can ignore the value and toggle the mute state based on some internal variable value. But doing so will remove the possibility of controlling the fader using the button.

I have read the documentation links. I think everything is very well explained.

In the Scripts Events page, the code examples of (@Timer), Fader, and V-Pot are in white color instead of using the red-green-blue combination. And there is a missing "{" in the second line of the last timers example of the Timers page.

I also haven't seen documentation regarding the following script actions and functions:

• {speed:}
  
• {textupper:}
  
• {design:}
  
• {vu:}
  
• {icon:} {iconupper:}
  
• {iconsize:} {iconuppersize:}
  
• {iconposition:} {iconupperposition:}
  
• Math functions to transform milliseconds in hours, minutes and seconds
  
• LPAD and RPAD
  

Oops.

It's a major update with a lot of improvements, I think it's normal to forget to document some changes.

I have been testing a lot all the generic midi configurations and everything seems to work perfectly.

Thanks for your kind words.

A final(?) update.

• I have fixed some minor bugs and UI issues.
  
• I have added a bunch of dB-scaled fader designs.
  
• I have added a feature where the {design:___} script action can reference designs by name instead of path. For example, you can use {design:Blue} to get the built-in Blue design. This can primarily be used for built-in designs but also for custom designs if the design has been referenced with the path from somewhere else (so the plugin is aware of the path to the design).
  
• I have updated the Elgato CSS as recommended by Elgato in preparation for an upcoming Stream Deck release. Please report if you see any UI artifacts due to this.
  

Version 3.10.0.930

Everything works fine. Referencing the design by name is very useful.

As usual, when I start to make videos to explain new features, I find minor problems.

I need to review the new button's Note On/Off part. It isn't clear what "Off" means, and it isn't clear when and how a Note Off is sent.

Admin wrote:I don't know if I fully understand you, but if you set the fader speed to 0, you will get a single (fader) event every time you press the button without having the fader move (in effect, a (press) event).

With a (fader:*) event, you can ignore the value and toggle the mute state based on some internal variable value. But doing so will remove the possibility of controlling the fader using the button.

Hmm, I still don't get it. Perhaps it would be helpful to have a detailed fade / vpot event with its variables described in the "Examples" section.

And I still don't get what you want to do.

Please explain what you mean by "overload the fader with a press event".

If I understand you correctly, you have something like this:

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

When you press the button, you control the fader, and you will get (fader) events.

The plugin can't magically know if you want to trigger a (fader) event or a (press) event when you press the button, so you need to choose.

If you want to do something else than controlling the fader when you press the button, you can set the speed to 0, in which case you will get one (1) (fader) event when you press the button, and you can treat that as a (press) event if you like:

[(fader:*){cc:1,5,127}]

I am currently using this code to switch "mute" and to display "mute", "volume" and "VU" infos on the button:

[(fader:*){cc:2,2,127}]
[(cc:2,2,127){icon:%trevligaspel%\WaveLinkXLR\Wavelink\Mute_red.png}]
[(cc:2,2,0){icon:#none#}]

[(init)(cc:2,1,*){value:#@e_ccvalue#}]
[(cc:2,1,*){value:#@e_ccvalue#}]

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


There are two problems:
1. I can only send mute {cc:2,2,127} when Fader speed is set to > 0. Fader speed = 0 - nothing happens
2. In case the "Mute" status is set and I have to switch the profile, it is not correctly updated when I return.

It sounds like a bug; let me check it.

Yes, it was a bug, sorry. Corrected in this version.

Version 3.10.0.939

1. is sovled by the patch   
2. is still open. I don't find a way to initialize the mute info or to store the info using a variable.


[(fader:*){cc:2,2,127}]
[(init)(cc:2,2,*){value:#@e_ccvalue#}]
[(cc:2,2,127){icon:%trevligaspel%\WaveLinkXLR\Wavelink\Mute_red.png}]
[(cc:2,2,0){icon:#none#}]

[(init)(cc:2,1,*){value:#@e_ccvalue#}]

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

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

You have no (init) command for the mute state, so it isn't restored.

The script looks odd. You send CC2,2 when the fader is moved, but move the fader when you receive CC2,1.

Try this (...assuming that CC2,1 is for the fader and CC2,2 is for the mute state):

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

[(init)(cc:2,2,127){icon:%trevligaspel%\WaveLinkXLR\Wavelink\Mute_red.png}]
[(cc:2,2,127){icon:%trevligaspel%\WaveLinkXLR\Wavelink\Mute_red.png}]
[(cc:2,2,0){icon:#none#}]

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

Admin wrote:The script looks odd. You send CC2,2 when the fader is moved, but move the fader when you receive CC2,1.

 That is what it is. The button is supposed to to the following things:
 - display the current fader value (CC1)
 - display current VU infos (CC11)
 - display & switch mute state of the channel (CC2)

This code does the work, although I don't know why exactly...

[(fader:*){cc:2,2,127}]
[(init)(cc:2,2,127){icon:%trevligaspel%\WaveLinkXLR\Wavelink\Mute_red.png}]
[(cc:2,2,127){icon:%trevligaspel%\WaveLinkXLR\Wavelink\Mute_red.png}]
[(cc:2,2,0){icon:#none#}]

[(init)(cc:2,1,*){value:#@e_ccvalue#}]
[(cc:2,1,*){value:#@e_ccvalue#}]

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

It now works because you have an (init) command for the mute icon, which you didn't have before.

I'm investigating what it would take to add an (init+) command that works both for init and normal use. Now, you often have to use two similar commands...

[(init)(cc:2,1,*){value:#@e_ccvalue#}]
[(cc:2,1,*){value:#@e_ccvalue#}]

...one for the (init) phase and one for the normal operation. Perhaps it would simplify things if you could have a single command...

[(init+)(cc:2,1,*){value:#@e_ccvalue#}]

...that would cover both cases. The "+" sign indicates that the command will also be active when it is not an init phase.

(init+) will be very useful, good idea!

This version has the (init+) event type.

Version 3.10.0.941

This update has a breaking change compared to the previous version.

I decided to change the fader/vpot scripting behavior when the speed is set to zero. In the previous version, you always got (fader)/(vpot) events regardless of the speed setting, which I found hard to handle in the script. I have now changed the logic so the script will receive (press)/(release) events if the speed is 0 and (fader)/(vpot) events if the speed is 1-100.

I'm now finalizing the YouTube videos based on this version, so this is very close to the final version.

Version 3.10.0.963

I will wait for the documentation. After the last patch my scipt for the combined fader/mute generic midi scipt stopped working when setting fader speed = 0. You can switch the mute state when setting fader speed > 0, but this very unstable and unreliable.

The doc won't say much other than that you need to have a (press) event to capture a button press if speed = 0.

So, if you have a (fader) event for the mute state switch, you need to change it to a (press) event. That should be all.

I am really confused atm. I thought the idea of scripts was to use fader and press events with the same button. 

Do I need to use a script (Legacy) button for that in the future? Because, when I choose a scripted Fader button type on a Generic Midi button, I couldn't use a {press} event inside it. 

I am really struggling with the current documentation to understand the big picture.

The only thing I wanna do with a single button is:

 - display a current fader value (CC1)
 - display the current VU infos (CC11)
 - display & switch mute state of the channel (CC2)

I'm sorry if I confused you.

If you before had something like this:

[(cc:1,11,*){vu:#@e_ccvalue#}]
[(cc:1,1,*){fader:#@e_ccvalue#}]
[(cc:1,2,0){icon:_path_}]
[(cc:1,2,127){icon:_path_}]
[(fader:*){cc:1,2,127}]

...you need to change it to...

[(cc:1,11,*){vu:#@e_ccvalue#}]
[(cc:1,1,*){fader:#@e_ccvalue#}]
[(cc:1,2,0){icon:_path_}]
[(cc:1,2,127){icon:_path_}]
[(press){cc:1,2,127}]

You only need to replace the (fader) event with a (press) event.

All this is provided that you have set the fader speed to 0; if you have a fader speed of 1-100, you will not get (press) events, then you will get (fader) events. I made this change to make it easier to have separate actions when speed = 0 and when speed = 1-100.

Think of it as the button being in "button mode" when the speed = 0, and you will get (press)/(release) events , and in "fader mode" when the speed is 1-100 and you will get (fader) events.