3.10.0.5 beta / 3.11 alpha

thx538 wrote:What I would like to do with the plugged/unplugged events is to activate/deactivate those scripts portions in Live and also the corresponding sysex processing in in Bome Midi Translator, so as to avoid unnecessary midi chatting for performance reason.

What I don't understand about these activate/deactivate requests is whether you guys really physically disconnect/connect your Stream Deck devices. I never do, and I can't really see the reason why I would.

The plugin can detect a device's physical connection or removal but does not know what profile is loaded on it. If you have a dedicated Stream Deck device with a single profile for a specific purpose and physically disconnect it from the USB port when you are not using it, I can see the point, but otherwise, not.

Hi Gunnar

I have sent you the profile and the xml scripts I have used, where you should see the double handles. Maybe I have done something wrong in the scripts that is causing the error.

Regarding VU question, my problem is that I don't know wich channel and wich cc is receiving the VU signal.

So I suppose that the problem is that I haven't configured a channel/cc number in Cubase/Live to send the level of the track.

How do I configure the channel and the cc number in Cubase/Live?

Thanks!

Thanks for the files.

The problem with the double handles is that you have set the button orientations to "Single horizontal".

The documentation that I eventually will have time to write will clarify the use of orientation settings.

• "Single horizontal" is just that - a single button horizontally orientated.
  
• "Auto" is everything else. If the button is single (either a script button defined as single or a non-script button where no companion is found), it will be a single button vertically oriented. If a companion is found vertically or horizontally, the plugin will adapt to the detected orientation.
  

The SHIFT button doesn't have the intended effect because the fader button...

1. Moves
   
2. Then tells the script it has moved.
   

So, regardless of the state of the SHIFT variable, the fader will move. Is having a shift button that disables other buttons an important function in your setup, or was it only something for a test case? The current solution can't handle it, so I need to decide how to proceed.

The VU functionality is there mainly because the display function was already implemented (for Mackie). I simply enabled it for non-Mackie buttons as well, just in case someone has VU information available. I don't know how to get VU information from Cubase, but maybe it is possible with the new Midi Remote.

Even though the function is labeled "VU", it doesn't have to be VU information; you can, of course, configure anything to be displayed as "VU" on the button. You can't control it with the button, but you can see it. You could, e.g., have a mixer channel fader show the channel fader position on the fader and a group channel fader position as "VU".

...moving on to the other reported problems...

Thanks for the explanations!

1) Double handle: well noted, not an issue, just my ignorance 

2) VU
Finally I have routed the VU from Cubase to Midi plugin using the Midi Remote. 

When VU is enabled (configured to receive values) the fader reacts extremely slow to the fader movements inside Cubase. 

When VU is disabled (nothing configured to receive values) the fader reacts faster to the fader movements inside Cubase, but I feel it slower than mackie faders or not scripted faders (mainly when the fader have to go down).

When pressing the SD+ buttons to move faders, the communication to Cubase is perfect, no matter VU is enabled or disabled.

Here is a video to show the fader behaviour when VU is enabled:
https://youtu.be/t-bUiDKJHlA

And another one with disabled VU:
https://youtu.be/DYfT9ZxO7ZM

3) UPPER FADER BUTTON MESSAGE
There is a message warning to use the lower button for script definition. Do we have to use one script per button (2 scripts) or only 1 script per combo faders?



4) MULTI-EVENTS (SHIFT BUTTON)
I have to go out now. I will explain you later regarding this question.

Yes, performance is a genuine concern. I haven't tried to speed things up, and there is a lot of cross-button communication, so things are probably performed multiple times.

I need to look into this and see if I can get good performance with the current design or if I need to redesign the internal logic.

You have given me good feedback and a lot to think about, so I suggest we pause the alpha testing for a while until I have sorted out the reported issues.

Admin wrote:What I don't understand about these activate/deactivate requests is whether you guys really physically disconnect/connect your Stream Deck devices.

Well ... Yes and No. I  use a USB hub with On/Off switches so when I want to connect or disconnect a device I use the switch.

Admin wrote:If you have a dedicated Stream Deck device with a single profile for a specific purpose and physically disconnect it from the USB port when you are not using it, I can see the point, but otherwise, not.

So using the switch is like physically connecting / disconnecting the StreamDeck, which I only use for DAW control.

@thx538 I think you could detect connection to stream deck+ using Bome Midi Translator:

- Create a loop in Bome to send a note on/off to Stream Deck, i.e. every 1 or 2 seconds

- Create or edit a Background Script in Global Settings of the Midi Plugin in Stream Deck to reply to the note on/off received with another midi message

- if Bome doesn't receive the reply after sending the note on/off, disable the midi communications you want to cut

- Bome keeps sending the note on/off even there is no reply from stream deck

- if Bome receive again a reply after sending the note on/off, enable the midi communications

jordikt wrote:
-Create or edit a Background Script in Global Settings of the Midi Plugin in Stream Deck to reply to the note on/off received with another Midi message

This doesn't work as connection detection. Background scripts will respond to incoming messages as long as the Stream Deck software runs, regardless of whether any devices are connected. Connecting or disconnecting a device changes nothing.

jordikt wrote:
Finally I have routed the VU from Cubase to Midi plugin using the Midi Remote. 

Please share your Midi Remote configuration for that.

It would be nice being able to send a self defined midi message when slowing the Fader Speed to 0 in a way like the Mackie Control action does. This way we would enable us to mute or solo for example.

Midi Remote configuration sent

Version 3.10.0.5 has now been sent to Elgato for publishing.

I've worked extensively with the graphics routines to speed up the 3.11 alpha and fix the reported problems.

Version 3.10.0.285

Joerg wrote:It would be nice being able to send a self defined midi message when slowing the Fader Speed to 0 in a way like the Mackie Control action does. This way we would enable us to mute or solo for example.

What do you mean??  
The Mackie Control does not send "a self defined midi message", it sends the Mackie Control fader touch command.

It makes no sense to have a "speed 0" sending a self defined midi command instead of moving the fader; that's what you have push/toggle buttons for. If you want a fader display that reacts to incoming fader messages while sending a self defined midi command when pressed, you can do that with a script.

jordikt wrote:Midi Remote configuration sent

Thanks, I managed to get it to work.

Is anyone using the Generic Midi button with note commands?

Is the current implementation where you define notes with raw midi values or by typing the note name better or worse than having a 128 note name dropdown?

If you just want to use generic midi action to display the channel status and being able just to mute or solo the channel it makes sense to have an alternative midi message being send.

This works currently with the mackie action (using send touch message while fader speed is zero), but you are not able to optical display mute/solo status or display the volume info at a certain place on the button.   

There are all kinds of borderline usages of the plugin, and it doesn't make sense to have options for all of them; that's what scripts are for.

The Mackie Control does not send a self-defined message; it sends a fader touch command as it always does; the only difference with speed=0 is that it doesn't send fader commands after that.

You want a Toggle button with a fader display, which, in my view, is definitely among the "borderline usages" that should be solved with a simple script. I agree that the current script syntax for fader display isn't perfect for this situation, but I think it would be better to see how to simplify that rather than building all kinds of exception rules in the editor.

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.

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.

The main difference of my proposal is to change the point of view. Instead of focusing of what is the value of the fader/vpot, I would focus to which midi message is linked to the fader/vpot and consider the fader/vpot just a representation of the linked midi value.

My idea is to use the current events and current actions, including the (press) and (release) events, just adding the command "link" and "unlink" to the midi messages. New events or new actions would be not necessary.

The following script should be enough to run a scripted fader/vpot:

[(init) {cc:1,1,link}]

An scripted fader/vpot with this script would work as a non-scripted fader/vpot. Pressing the button increases/decreases the value of cc:1,1,*, sends the value to the DAW, and updates the fader/vpot representation of the linked midi value. If the Midi Plugin receives any value of cc:1,1,*, it would update the fader/vpot representation according to the received midi value.

User could modify the linked midi message easily anytime in anyway. As example, adding the following (press) event, the fader/vpot button would change the linked midi message to 2,2,* the first time the button is pressed:

[(init) {cc:1,1,link}]
[(press) {cc:2,2,link}]

So a "link" command inside an action replaces the previous link with the new one.

If two link actions are contiguous in the same line, both links are linked together, replacing the previous link. In the following example, pressing the button will send cc:2,2,* and cc:3,3,* updating the fader/vpot accordingly. Anytime the Midi Plugin receives any value from cc:2,2,* will update fader/vpot and will also send cc:3,3,* with the same value of cc:2,2,*. If the Midi Plugin receives any value from cc:3,3,* will update fader/vpot and will also send cc:2,2,* with the same value of cc:3,3,*. 

[(press) {cc:2,2,link} {cc:3,3,link}]

User could also change the link depending of other values. The next example would change link and text of the button depending on the compressor mode selected:

[(press) (@compMode:COMPRESSOR) {cc:1,1,link} {text:COMPRESSOR}]
[(press) (@compMode:LIMITER) {cc:2,2,link} {text:LIMTER}]

User could also unlink any linked midi message. The next example would send two linked midi messages when button is pressed, but the fader/vpot would only react when receiving cc:3,3,*

[(press) {cc:2,2,link} {cc:3,3,link}]
[(release) {cc:2,2,unlink}]

This command would also be useful to disable a button depending a variable. The following example would disable the fader/vpot button representation: p ressing the button would not save any midi message and not moving the fader/vpot:

[(press) (@Chorus:ON) {cc:1,1,link} {text:CHORUS ENABLED}]
[(press) (@Chorus:OFF) {cc:1,1,unlink} {text:CHORUS DISABLED}]

The performance of faders with VU and also knobs has improved a lot. Everything seems to work flawlessly.

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.

Maybe it's a bug in Cubase that sends wrong values for the VU. In the video you can see the value of the cc in the dial below the 2 buttons fader.

Short video: 
https://www.youtube.com/shorts/vHMEEo4rE_c

1) The bug of frozen Generic Midi Vpot image seems to be not fixed.

2) The bug of both directions of Generic Midi scripted Vpot is fixed.

3) 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? Short video of this issue: 

https://youtu.be/ODhsVuG-mN4

Admin wrote:

Is the current implementation where you define notes with raw midi values or by typing the note name better or worse than having a 128 note name dropdown?

For me it's better now, typing the value.

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?

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.

jordikt wrote:1) The bug of frozen Generic Midi Vpot image seems to be not fixed.

2) The bug of both directions of Generic Midi scripted Vpot is fixed.

3) 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? Short video of this issue: 

https://youtu.be/ODhsVuG-mN4

1) Yes, I found it.

3) 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.