Re: 3.10.0.5 beta / 3.11 alpha

by **Admin** Wed Jun 19, 2024 7:23 pm

jordikt wrote:The upper text seems to work better than before, but I am experiencing another weird issue...

What I can see, the two scripts in that post are identical, and the first script can never produce what you show in the video.

by **Admin** Wed Jun 19, 2024 7:26 pm

jordikt wrote:Script changes of speed work fine except if you want to change the speed depending of the position of the fader.

Yes, I know. I realized that when I implemented the speed control, but it's a bit tricky to change on the fly since the fader movement is performed by a separate process. I'll see if I can solve it reasonably easily.

by jordikt Wed Jun 19, 2024 7:28 pm

Admin wrote:
jordikt wrote:The upper text seems to work better than before, but I am experiencing another weird issue...

What I can see, the two scripts in that post are identical, and the first script can never produce what you show in the video.

I have edited the post of that issue, saying that the issue has gone and I cannot reproduce it again.

But the video I saved was using the first script.

by **Admin** Wed Jun 19, 2024 7:30 pm

jordikt wrote:The handle of the scripted faders are over the icons if both items are in the same position.

Is it by design?

Yes, it is by design. I.e., it happened to be that way when I changed the rendering order. Smile

I was aware of that when I made the change, but I wasn't sure how to prioritize so I tried this way. Maybe it wasn't the best solution.

by **Admin** Wed Jun 19, 2024 8:43 pm

The state icon is rendered above the fader handle.
Speed changes from a script are immediately used.
Bug fix to prevent a crash if a button is unloaded less than 200 ms from when it is loaded,

Version 3.10.0.482

by jordikt Thu Jun 20, 2024 1:54 am

It seems that speed changes on the fly are causing also undesired increases/decreases of midi values.

I have recorded two videos, one showing midi values at the right side.

The only action I do in both videos is to press and hold the upper button of the synchronized faders at the beginning of the video. Just one press. When I release the button at the end of both videos, the fader jumps to zero. Even I do the same action in both videos, the jumps and movements of the fader are different.

Restarting SD is not fixing this issue. I am not running any DAW in these tests, only SD editor is running.

Videos:
https://youtu.be/4thZV_1M_2M
https://youtu.be/cpRQIp1p0Kw

The code used in the lower fader is:

[(init) {value:#@value_3rd_fader#} {text:#@value_3rd_fader#} {textupper:3-F Range}]
[(cc:1,39,*) {value:#@e_ccvalue#} {text:#@e_ccvalue#} {@value_3rd_fader::#@e_ccvalue#}]
[(fader:*) {cc:1,39,#@e_fadervalue#}]

[(cc:1,39,0-40) {speed:100}]
[(cc:1,39,40-60) {speed:80}]
[(cc:1,39,60-80) {speed:60}]
[(cc:1,39,80-100) {speed:40}]
[(cc:1,39,100-127) {speed:20}]

by jordikt Thu Jun 20, 2024 2:04 am

Admin wrote:
Weird behaviour with the script file selection. This lower fader button is changing the script path automatically pointing to an old script file that currently doesn't exist

Script settings aren't synchronized. I can't reproduce this problem, and I get the impression it's a Stream Deck bug rather than a plugin bug. You say you deleted the button and recreated it in the same place. It should be impossible for the "new" instance of the plugin to know about values from the previous instance, but I have sometimes seen that new instances that replace old instances of the same type sometimes inherit settings in some mysterious way. It is impossible for the plugin to do something like that, so it must be a Stream Deck problem.

I agree that it is a SD bug.

I have also experienced things like this before, new instances that take values of previous deleted instances.

Would it help that you explain this bug to SD? Are they receptive?

by jordikt Thu Jun 20, 2024 2:11 am

Admin wrote:
Synchonized faders/vpots controlled by an script that contains {design} actions are showing the drop-down menu of designs instead of showing the message "Controlled by script".
Yes, I mentioned this a while ago. I no longer keep separate settings for the script and the editor. The script is changing the setting in the editor so there is no longer any confusion when you change it manually. The selected design will be changed when you change it in the editor and when the script is changing it. Do you still think it should be hidden (or maybe have the "controlled by script" message along with the dropdown?). The same thing, btw, is true for the speed, it can also be changed both from the script and manually.

IMHO this current configuration is more than PERFECT.

I thought it was not possible to change designs manually and from the script without having problems.

But as I said, the current configuration is perfect for speed and design changes from editor and from script.

by jordikt Thu Jun 20, 2024 2:28 am

Admin wrote:
jordikt wrote:It would be useful to have a trash icon next to the script file selection to remove the script file.
I have never seen any use for such a function. If you say you want to use a script file, you need a file reference; if you select not to use a script file, the file reference is (or should be) ignored. It makes no sense to me to say you want a script file and then remove the file reference. I think your request comes from the bug where script references were synchronized between buttons, which they should not be.

Since I started using the Midi plugin scripts, I miss the option to remove the script file link and leave empty that link (leave it as it is in a new script button).

It's also true that I posted this wish when I experienced these problems with the script link, as you say.

Probably I miss it because it is a common option in apps to remove items after load them.

Anyway, you are right that we can disable the checkbox of "Load script from file" and it is similar to remove the link to the file. So I agree with you that removing the link to script file is not a must.

by jordikt Thu Jun 20, 2024 3:49 am

Admin wrote:
In the upper button, instead the sentence "Please use the lower button for script definition", we could have a drop-down menu with the names of existing script files of lower buttons with a label like "Select the lower button you want to link this upper button"
What would be the difference besides the very odd fact that you may link two buttons that are not adjacent?

The difference is jus that the two scripted faders/vpots are combined by an user action, not by the Midi plugin.

It seems to me that combining faders/vpots with a user action is easier than combining them with a software interpretation, so maybe it would result in a more stable software with less possibility of errors. But maybe I am wrong and this configuration would be problematic.

The current configuration works fine, so my proposal was not for fixing a problem. It's just an idea that I wanted to share for your consideration.

by jordikt Thu Jun 20, 2024 3:36 pm

The options of fader direction and fader orientation could change depending of the selected button role.

If the selected role is "Single", the fader orientation and fader direction could hide the "Auto" option, and only show two options for fader direction: "Vertical" and "Horizontal", with "Vertical" as default.

If the selected role is "Upper" or "Lower", the whole fader orientation could be hidden and set to "Auto". In this case, fader direction could show the three current options, or also be hidden and set to "Auto".

These changes could be applied to scripted faders and also to non-scripted faders.

by jordikt Fri Jun 21, 2024 12:04 am

Scripted vpot has some issues:

1. TEXT
The text is not changing when the vpot is pressed. It only changes when the midi is received from DAW. The code to replicate this issue is:

[(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,0) {text:MIN}]
[(cc:1,39,127) {text:MAX}]

2. DESIGN CHANGES
3. SPEED CHANGES
The design and the speed are not changing when the vpot is pressed. They only change when the midi is received from DAW. Code to replicate these issues:

[(init) {design:%trevligaspel%/My VPot/ParametersCyanRing/ParametersCyanRing.xml}]
[(cc:1,39,*) {value:#@e_ccvalue#} {text:#@e_ccvalue#}]
[(vpot:*) {cc:1,39,#@e_vpotvalue#}]
[(cc:1,39,0) {design:%trevligaspel%/My VPot/VpotRedRing/VpotRedRing.xml} {speed:100}]
[(cc:1,39,127) {design:%trevligaspel%/My VPot/VpotOrangeRing/VpotOrangeRing.xml} {speed:50}]

4. CUSTOM DESIGNS
This is an issue that was fixed previously. The custom designs are not loaded from scripts if they are not loaded previously in the drop-down menu.

by **Admin** Fri Jun 21, 2024 9:52 am

I'm on a midsummer break, but I will look at your reports when I return.

by jordikt Mon Jun 24, 2024 2:24 pm

3.10.0.482 fixed the frozen message of plugin is loading, but I am still experiencing performance problems that began with version 3.10.0.479

My SD+ gets frozen very often (it doesn't respond to buttons or dials).

It also goes very slow sometimes (it takes 20 seconds for changing a profile).

Everything is fixed after a restart of the device, but I am experiencing one or both problems in almost every music session I start.

by **Admin** Mon Jun 24, 2024 9:52 pm

jordikt wrote:It seems that speed changes on the fly are causing also undesired increases/decreases of midi values.

Fixed.

jordikt wrote:The options of fader direction and fader orientation could change depending of the selected button role.
...
These changes could be applied to scripted faders and also to non-scripted faders.

Fixed, but these changes cannot be applied to non-scripted faders. I also made a similar change to the VPot.

jordikt wrote:Scripted vpot has some issues...

Fixed.

In addition, I have changed the fader state icon position/size control. It is now completely free, as opposed to the fixed position/sizes used before. The icon size can now be increased up to the full button size, enabling, e.g., a mute icon to replace the fader. Icon positions made with the previous version are not migrated, so you need to restore the positions if you have changed them from the default. Sorry.

jordikt wrote:3.10.0.482 fixed the frozen message of plugin is loading, but I am still experiencing performance problems that began with version 3.10.0.479

My SD+ gets frozen very often (it doesn't respond to buttons or dials).

It also goes very slow sometimes (it takes 20 seconds for changing a profile).

Everything is fixed after a restart of the device, but I am experiencing one or both problems in almost every music session I start.

I cannot reproduce those problems. It sounds like a memory leak problem, but I cannot detect any memory leaks in my tests. In this new version, I have fixed several minor bugs, so try it out and see if those problems are fixed. If not, it would be interesting to see a log file.

Version 3.10.0.568

by jordikt Tue Jun 25, 2024 5:19 pm

Scripted v-pot: Issue when doing these steps:

- Set to single
- Set rotation to both ways
- Set to lower/upper
- The checkboxes of both ways remains visible

by jordikt Tue Jun 25, 2024 5:56 pm

The new fader icon position and icon size is great.

Minor issue:
- Set icon size to mid value
- Move the white square of the icon position to one of the corners
- Move the slider of icon size to the maximum
- The icon of the button is centered at the maximum size, but the white square that is representing that icon is set also to the maximum size, but not centered
- Clicking the white square centers the white square correctly

Suggestions:

- Add a numeric field for size and a numeric field for position. That would help to set the same configuration between different buttons, copying/pasting their values.

- Use both numeric values to script icon size and icon position, with two new scripting actions

by **Admin** Tue Jun 25, 2024 6:30 pm

I use a standard jQuery component for the icon position control. I also noticed the behavior you described, but jQuery is not my field of expertise, so I decided to let it be. Even though it looks odd, it isn't a major issue.

I've also considered adding numerical fields for position and size and agree it may come in handy.

I expected a request for scripting access to the size/position. Very Happy

by jordikt Tue Jun 25, 2024 6:56 pm

Admin wrote:I expected a request for scripting access to the size/position.

I expected that you expected that!!! Very Happy

by jordikt Tue Jun 25, 2024 7:04 pm

The following script works perfectly. It is a counter of single/double/triple press. If button is pressed more than three times, the button prints "More than triple press".

[(init) {@pressCounterTwo:0} {text:Press…} {@t_pressCounterTwo:reset}]
[(press) {@pressCounterTwo:#@pressCounterTwo+1#} {text:Counter\n#@pressCounterTwo#} {@t_pressCounterTwo:run}]
[(@t_pressCounterTwo:2000) (@pressCounterTwo:1) {@t_pressCounterTwo:reset} {@pressCounterTwo:0} {text:Single\nPress}]
[(@t_pressCounterTwo:2000) (@pressCounterTwo:2) {@t_pressCounterTwo:reset} {@pressCounterTwo:0} {text:Double\nPress}]
[(@t_pressCounterTwo:2000) (@pressCounterTwo:3) {@t_pressCounterTwo:reset} {@pressCounterTwo:0} {text:Triple\nPress}]
[(@t_pressCounterTwo:2000) (@pressCounterTwo:4-99) {@t_pressCounterTwo:reset} {@pressCounterTwo:0} {text:More than\nTriple\nPress}]

If I change the variable event of the last line to (@pressCounterTwo:>3>) the script fails if I press more than three times.

I wonder if it is a bug or something that I don't understand regarding the "<value<" or ">value>" commands.

Could you give some light here? Thanks.

by jordikt Tue Jun 25, 2024 7:32 pm

After testing the last version during some hours, it seems that it works perfectly, except the minor issues reported before.

The frozen/slow problems are probably fixed in this last version, as I haven't experience any issue. Anyway, I have the extended logging enabled, and I will report if something weird happens.

by **Admin** Tue Jun 25, 2024 7:52 pm

If you set (@pressCounterTwo:>3>), the event is already handled by the (@pressCounterTwo:3) event, so it will never be run.

If you set (@pressCounterTwo:>4>), it works if you press exactly 4 times, but not if you press more times.

>4> means it will trigger when the previous value is below 4 and the current value is 4 or above.

If you press 5 times, the "previous value" is 4, so it will not trigger the event.

by jordikt Tue Jun 25, 2024 8:20 pm

Admin wrote:>4> means it will trigger when the previous value is below 4 and the current value is 4 or above.

If you press 5 times, the "previous value" is 4, so it will not trigger the event.

Thanks, that's the logic I didn't understand.

So, in this case, there is something like (@pressCounterTwo:>3) that I can use to trigger actions when the value is higher than 3?

by **Admin** Tue Jun 25, 2024 8:32 pm

jordikt wrote:So, in this case, there is something like (@pressCounterTwo:>3) that I can use to trigger actions when the value is higher than 3?

Unfortunately not. The script engine handles exact values, intervals (4-99), all values (*) and transition (>4>), but not higher/lower than. Your initial solution with an interval should be the best in this case.

by jordikt Tue Jun 25, 2024 8:45 pm

It would be useful to have an easy way to transform milliseconds to hours, minutes and seconds if we want to print the values of the timers in a familiar way.

Maybe some new math functions would be useful for this goal, something like:

HHMMSS(number) : show the milliseconds as hh:mm;ss

HHMM(number) : show the milliseconds as hh:mm

MMSS(number) : show the milliseconds as mm:ss

Then we could print only minutes and seconds of a timer with this code:
[(@t_timer:1000) {text:#MMSS(@t_timer)#}]

by Sponsored content