Beta version 4.3

[Gunnar]

@jordikt

But the {outputport:GPx} action is not working even you use GP1-GP10.

Yeah, that’s the action I mentioned that I failed to test before publishing the beta.

I have removed all syntax checks for the port name. It was a bad design because you should be able to register any port, not just global ports.

I will probably be able to publish a new beta tomorrow.

[thx538]

Hello,
I can confirme the Following issues are fixed :

• sysex Send not working
• font/weight taking precedence over forced calculations when set from script
• custom color setting with standard layouts

Btw is there a possibility to programmatically set custom colors, font size and weight for scripted buttons (as set from the editor, under the title section)?

[Gunnar]

I suddenly realized that the complete time/BPM functionality was absent from both the new MIDI connection logic and JavaScript, so I needed to fix that. I’m currently in the final testing phase.

@thx538

Btw is there a possibility to programmatically set custom colors, font size and weight for scripted buttons (as set from the editor, under the title section)?

Plugins can read the font settings made in the editor, but cannot change them.

To affect button fonts, the plugin must completely avoid text handling in the editor (e.g., text in the Title field) and embed text as part of an image sent to the button, which would force the plugin to also ignore images set in the editor.

[Gunnar]

This version has fixed script MIDI connection actions. It also has correct functionality for time and bpm.
New events:
OnTimeUpdated(time)
OnBPMUpdated(bpm)

New time calls:
midi.time.get() => time object
midi.time.text() => time as string: “hour:minute:second.frame”
midi.time.bpm() => bpm as int

example time object used in OnTimeUpdated() and time.get:
const time = {
hour: 1,
minute: 23,
second: 45,
frame: 12,
smpteType: 1,
smpte: “25 fps”,
bpm: 128
};

Version 4.2.0.100

[jordikt]

I’m testing the reception of midi messages with the following code, but it always shows 0 in the display:

[(cc:2,2,*) {@l_value:#e_ccvalue#} {text:#@l_value#}]

Am I doing something wrong in this line of code?

[Gunnar]

@jordikt

Am I doing something wrong in this line of code?

Yes, there is no @ prefix for e_ccvalue.

[jordikt]

Thanks.

I remember there was a documentation page with all the reference variables that you created in one of the last betas. I’ve been looking for that page on the website and I can’t find it.

Do you know which page I’m referring to? Is it posted in the documentation? I can’t find it.

[Gunnar]

@jordikt

Do you know which page I’m referring to? Is it posted in the documentation? I can’t find it.

No, I’m not sure what you mean. I previously had a page in the documentation covering all reference variables, but I figured it would be more logical to describe the variables alongside the events, so they are now on the events page.

[jordikt]

The new actions for changing/selecting input and output ports in scripted dials and buttons are working as expected in my setup (last beta version 4.2.0.100)

[jordikt]

Some minor things:

1. The release notes are not showing the new actions for changing ports

2. About the “run init commands” confirmation dialog, have you considered whether to keep it or remove it?

3. I‘ve realized that if I send a midi message thought the midi channel 17, it is sent through midi channel 1. If I sent another thought the midi channel 18, it is sent through midi channel 2, and so on. I’m telling you in case you didn’t know, so you could appreciate it if you leave it like this or report an error in the editor (and also not send the midi message).

[thx538]

I have an issue with setting a layout property with the following statement :

layout.l_bar_main_pan.opacity = 0.5;

The opacity does not change.
Log Id: 70e22707-23c8-4894-aed5-c1425d6f32b6

… and then something very strange happens. If I change the line to :

//layout.l_bar_main_pan.opacity = 0.5;
layout.l_bar_main_pan.enabled = false;

The previous error persists.
Log Id: f937a701-238a-46c6-8f82-8ba2a44c678e
How is it possible ?

It may be not be related but after this error, if I quit the streamdeck app and restart it, the communication with the daw is broken. I have to reboot my computer.

[Gunnar]

@jordikt

The release notes are not showing the new actions for changing ports

There are many “minor” things that aren’t listed on that page. Maybe the port commands should be included there. I’ll finalize the page once everything has settled.

@jordikt

About the “run init commands” confirmation dialog, have you considered whether to keep it or remove it?

I added it as a “could maybe be good to have”. Do you think it is unnecessary?

@jordikt

I‘ve realized that if I send a midi message thought the midi channel 17, it is sent through midi channel 1.

Thanks, this should be listed as a script error.

[thx538]

@thx538

It may be not be related but after I quit the streamdeck app and restart it, the communication with the daw is broken. I have to reboot my computer.

After rebooting my computer, i can set layout.l_bar_main_pan.enabledto true or false and it works as expected.

So it seems in some cases the midi communication is broken after the opacity persistence error. It happened a number of times when errors occurred, but is difficult to reproduce (not always the case).
Any idea ?

[jordikt]

@Gunnar

@jordikt

About the “run init commands” confirmation dialog, have you considered whether to keep it or remove it?

I added it as a “could maybe be good to have”. Do you think it is unnecessary?

Yes, it is unnecessary for me.

@jordikt

The “Run Init“ button works like a charm. This is a button to save time when testing changes in the actions of the (init) event, but the confirmation dialog slows down the workflow. I would propose to keep the dialog but with a “Don’t show this confirmation again“ checkbox, or just remove it.

[jordikt]

@Gunnar

There are many “minor” things that aren’t listed on that page. Maybe the port commands should be included there. I’ll finalize the page once everything has settled.

I would also highlight that now the qty of global ports can be increased

[Gunnar]

@thx538

The opacity does not change.

I think this is a language-dependent issue. Your pasted command had “0.5” but the log file says “0,5”. I need to investigate how to avoid changing the decimal point…

@thx538

So it seems in some cases the midi communication is broken after the opacity persistence error.

These errors can’t possibly be related. Which MIDI system do you connect to?

[jordikt]

This code was working in previous versions as expected:

TOGGLE SOLO BANK TRACK 1
[(rotate:pr){listoptions:list,release} {showlist: ,TOGGLE SOLO,focus=TOGGLE SOLO}]
[(selectedfromlist:TOGGLE SOLO){cc:11,31,127}]

SET CUBASE FADER TO -oo
[(rotate:pl){listoptions:list,release} {showlist:Set fader to -oo, ,focus=Set fader to -oo}]
[(selectedfromlist:Set fader to -oo){cc:11,1,0}]

If I change the rotate events for press events both lists are shown as expected. Could you replicate this issue?

[Gunnar]

@jordikt

If I change the rotate events for press events both lists are shown as expected. Could you replicate this issue?

What is the issue?

When I press/rotate, the lists are displayed, and when I release, the CC command is sent.

[jordikt]

@Gunnar

What is the issue?

The list is never shown when I rotate to left or right.

[jordikt]

I have upload a log file:
be25108d-b625-4177-a4ed-98fe6025d4f3

I am experiencing an issue with some scripted paired fader buttons that I have recently created. This is the first time I use scripted paired fader buttons in my setup (previously I only used them for beta testing).

Sometimes the text of some upper buttons is not shown.

At the end of the video I press twice the change of the profile that contains the paired fader buttons and it seems to fix it. (EDIT: IT fixes sometimes, randomly)

This is the video:

scripted paired fader buttons: textupper issue