Scripted dial alpha

Admin wrote:This version fixes a number of script problems and have some tweaked font sizes.
The handling of release events is better, but I'm still struggling with it.

What is the expected behavior from the following script:

[(release:n){text:N 1}]
[(release:r){text:R 1}]
[(release:n){text:N 2}]
[(release:r){text:R 2}]

Should the plugin find the following command in the sequence that fulfills the r/n criteria regardless of which kind of release event was last triggered?
...or...
Should the plugin find the following command in the sequence that fulfills the r/n criteria after the previous command that fulfilled the same criteria?

Or put another way: should a sequence of release commands of a certain kind (say "n") be completely independent of release commands of the other kind?

Version 3.11.0.348

IMO this is the logic behaviour:

[(release:n) {text:This text is shown if the dial is not rotated at 1st release, 3rd release, 5th release, etc}]

[(release:r) {text:This text is shown if the dial is rotated at 1st release, 3rd release, 5th release, ect}]

[(release:n) {text:This text is shown if the dial is not rotated at 2nd release, 4th release, 6th release, etc}]

[(release:r) {text:This text is shown if the dial is rotated at 2nd release, 4th release, 6th release, etc}]

So the following script should have the same behaviour…

[(release:n){text:N 1}]
[(release:r){text:R 1}]
[(release:n){text:N 2}]
[(release:r){text:R 2}]

…than this one:

[(release:n){text:N 1}]
[(release:n){text:N 2}]
[(release:r){text:R 1}]
[(release:r){text:R 2}]

Various things:

1) The "Avoid handle/text collisions" (fader menu) is the only property that is not scriptable. Maybe you want to add it?

2) The tic values we are getting are quite different. I think we should revise this matter. I wonder if we are using different scripts or if we are doing something different that can explain the differences we get.

3) The label for designs menu in the Generic Midi are “Fader design” and “”V-pot design”. The same labels in the rest of dials (Scripted Dial. Mackie Control, Multidial, Multimackie) are “Fader Display” and “V-pot Display”. Maybe you want to standarize all these labels to the same name. I think the label "Design" will be good for all them, as we use the {design:} command in the scripts.

4) I see that the order of the color selectors in Volume bar and Pan bar has not changed. Is it correct like now or it will be changed later?

Some feature requests regarding color:

1) V-pot text background

Usually the texts located on the v-pots are hard to read.
Having the option to select a background color as we have in the fader display, would help a lot to the readability of the text on the vpot.
This color option could be implemented on dials and buttons.

2) Script colors

It would be perfect to have actions to change the colors of the title and the text:
{titlecolor:FFFFFF}
{textcolor:DE1515}
{backgroundcolor:DE1515}

I need to revise the press/release system. Right now, it's a modified version of the button press/release, and it doesn't work. If you only have release commands, it kind of works, but n/r commands can disrupt the flow for the other kind. And if you have one single press command, the complete release system falls apart.

I don't know exactly what to do, but I'll figure it out.

jordikt wrote:1) The "Avoid handle/text collisions" (fader menu) is the only property that is not scriptable. Maybe you want to add it?

Yes, maybe, when everything else works.

jordikt wrote:2) The tic values we are getting are quite different. I think we should revise this matter. I wonder if we are using different scripts or if we are doing something different that can explain the differences we get.

Are we collecting the information the same way? My way is to enable logging and watch entries like these:

rotateEvent  SetBuiltinVariables  [a4702fb847ade917e749ab1e9c5e6129 tics=(4), value=(5)]

jordikt wrote:3) The label for designs menu in the Generic Midi are “Fader design” and “”V-pot design”. The same labels in the rest of dials (Scripted Dial. Mackie Control, Multidial, Multimackie) are “Fader Display” and “V-pot Display”. Maybe you want to standarize all these labels to the same name. I think the label "Design" will be good for all them, as we use the {design:} command in the scripts.

Yes, maybe, when everything else works.

jordikt wrote:4) I see that the order of the color selectors in Volume bar and Pan bar has not changed. Is it correct like now or it will be changed later?

The same fields are used for all kinds of displays, and the current order makes sense for other display types. I'd rather spend time fixing the things that don't work or adding new features than fixing pure cosmetic issues.

jordikt wrote:Some feature requests regarding color:

1) V-pot text background

Usually the texts located on the v-pots are hard to read.
Having the option to select a background color as we have in the fader display, would help a lot to the readability of the text on the vpot.
This color option could be implemented on dials and buttons.

2) Script colors

It would be perfect to have actions to change the colors of the title and the text:
{titlecolor:FFFFFF}
{textcolor:DE1515}
{backgroundcolor:DE1515}

Yes, maybe, when everything else works.

Sorry for being so negative, but I need to focus on getting the current functionality correct. I need to get the scripted dial released. After that, I know that Elgato is working on redesigning how the editor UI should look, and depending on what they come with, I may have a huge job ahead.

So, I need to get this working. Visual goodies and nice-to-haves must wait, I'm afraid.

Just FYI: I have done several scripts using press, release and timers for executing different actions when there is a single press, double press, and press and hold.
They have all worked very well.
I have always used (release:n) in these scripts, not (release:r)... (you know I am against that:D)

But if it helps in some way, you could consider to:
- kill the (release:r)
- kill the (release:n)
- keep only (release) and (press) and keep the logic of "a release needs a previous press"

I think using variables it's easy to manage the release events. You could publish some scripts in the web as example templates for manage the different kind of release events.

I think this works fine and it's easy to manage:

[(init) {@status:nothing}]

[(press) {@status:onlypressed}]
[(rotate:p) {@status:pressedAndRotated}]

[(release) (@status:onlypressed) {any action}]
[(release) (@status:pressedAndRotated) {any other action}]

And users can complicate it as they want for double releases, what to do when there is  sequence of releases, etc.

Admin wrote:Sorry for being so negative, but I need to focus on getting the current functionality correct. I need to get the scripted dial released. After that, I know that Elgato is working on redesigning how the editor UI should look, and depending on what they come with, I may have a huge job ahead.
So, I need to get this working. Visual goodies and nice-to-haves must wait, I'm afraid.

There is no problem, Gunnar.
I appreciate your honesty, I like that you are clear.
I will also focus only on the correct functionality, you are the captain of this boat! 

Admin wrote:

jordikt wrote:2) The tic values we are getting are quite different. I think we should revise this matter. I wonder if we are using different scripts or if we are doing something different that can explain the differences we get.

Are we collecting the information the same way? My way is to enable logging and watch entries like these:

rotateEvent  SetBuiltinVariables  [a4702fb847ade917e749ab1e9c5e6129 tics=(4), value=(5)]

Confirmed that using the log I have get +20/-20 also when abusing the SD+.

FYI: My mother passed away a week ago, so my focus is somewhat scattered at the moment. It's "ok" in the sense that she had excruciating pain at the end (due to blood cancer), so it was almost a relief that she no longer had to suffer.

But from time to time, I now have things to attend to that are far more important than the plugin; that's one of the reasons I try to minimize changes and focus on stability from now on.

I'm sorry your mom is gone. It must be a difficult time. A lot of feelings I suppose.

Thanks for sharing it.

Admin wrote:My mother passed away ...

Sorry for you loss and thank you for your dedication.
It's fun (and also hard work, especially for you) to interact as we did for this alpha.
The three of us are making a good team.

jordikt wrote:But if it helps in some way, you could consider to:
- kill the (release:r)
- kill the (release:n)
- keep only (release) and (press) and keep the logic of "a release needs a previous press"

Yes, I'm starting to think it's a good solution. Managing all possible combinations of press/releases in code has become a nightmare, and the resulting logic will be hard to explain and not very straightforward.

Additional empty (press) commands may be needed if you only want to have actions for (release) commands, but that's much easier to explain and understand.

If I have a single, simple (release) event, I can add an event reference variable for the "has been rotated" state to give some extra information about that.

thx538 wrote:The three of us are making a good team.

Yes. I really appreciate your help debugging the plugin and sharing your thoughts and ideas. It's sometimes a bit overwhelming but I prefer that to not having any feedback.

Admin wrote:Additional empty (press) commands may be needed if you only want to have actions for (release) commands, but that's much easier to explain and understand.

If you finally decide to choose to the solution of obligatory (press) below a (release) event, I would add a new action called {noaction}.

When I said it some posts ago, you said it was not necessary because you can just write the event (press) with no action.

I still think it would be good to have a {noaction} action for all the (press) events that has no action to do.

Why?

Because I think it is more clear to read and understand this...

[(press) {noaction}]

than this:
[(press)]

IMO, a press event alone seems like an error, that the code is incomplete, that something is missing.

Admin wrote:

jordikt wrote:But if it helps in some way, you could consider to:
- kill the (release:r)
- kill the (release:n)
- keep only (release) and (press) and keep the logic of "a release needs a previous press"

Yes, I'm starting to think it's a good solution. Managing all possible combinations of press/releases in code has become a nightmare, and the resulting logic will be hard to explain and not very straightforward.

Additional empty (press) commands may be needed if you only want to have actions for (release) commands, but that's much easier to explain and understand.

If I have a single, simple (release) event, I can add an event reference variable for the "has been rotated" state to give some extra information about that.

I understand and support the need for simplification.
But at the moment my scripts make heavy use of (release:n) and (release:r) events. So I guess the extra variable will enable to do the same and program a separate set of actions for each situation. Am I correct ?

Or otherwise how will we be able to distinguish the two situations ?

thx538 wrote:Or otherwise how will we be able to distinguish the two situations ?

[(init) {@status:nothing}]

[(press) {@status:onlypressed}]
[(rotate:p) {@status:pressedAndRotated}]

[(release) (@status:onlypressed) {@status:nothing}] --> this is the same than release(n)
[(release) (@status:pressedAndRotated) {@status:nothing}] --> this is the same than release(p)

Yes, thank you for the suggestion, ... I thought about something like that.

But as a simple solution, and as it is a very common pattern, I also thought it could be implemented in the core. Indeed it seems to work well since the last version.
I'll live with it if it is not.

I was also wondering if there are some side effects with Multi-event commands.

thx538 wrote:I was also wondering if there are some side effects with Multi-event commands.

If you are asking if multi-event commands has some problem or limitation compared with single event commands, I would say no (but some combination of events are not allowed).

I decided to keep the n/r flags in the release event, and I have added code to handle sequences of rotated and not-rotated release events separately.

This will allow for many complex combinations; I must decide how to explain it to users.

Basically:

• If there are one or more (press) commands in the script, everything works as for buttons; each (release) event is an attachment to the preceding (press) event, so you need multiple (press) events if you have multiple (release) events.
  Multiple (release) commands can be "attached" to the same (press) command if they have different n/r flags or are in multi-event commands; the first command found that fulfills all criteria will be used.
  {noaction} action is implemented, so you can use that or have a (press) event without any actions if you need an empty (press) command.
  
  
• If no (press) commands exist in the script, the plugin works in "release mode" and keeps track of two separate chains of (release) events for rotated and not rotated. The two chains do not affect each other; a triggered (release:r) does not affect which (release:n) will be the next event when not rotated, and vice versa.
  An important note is that (release) events (without parameter) and (release:nr) events (you can set both flags) belong to both chains, so there is a risk/possibility of complex flow between commands.
  

As far as I have seen in my initial tests, this works fine in multi-event commands, which enables even more complex command chains. If this is a good or bad thing, it is up to the script constructor to decide.

To test it, you can play around with this script and follow the chains:

[(release){text:F1}]
[(release:n){text:N1}]
[(release){text:F2}]
[(release:r){text:R1}]
[(release:n)(@val:0){text:N2:V0}]
[(release:n)(@val:1){text:N2:V1}]
[(release:r){text:R2}]
[(release:nr){text:NR1}{@val:1}]

Version 3.11.0.352

There is also an event reference variable available in release commands:

@e_rotated yes/no

Good Morning !
No issue on my side with this new version but I don't use all the capabilities :

• I don't use (press) events
  
• I only use two release events: (release:n) and (release:r), so it is the "release mode" with no cycling involved
  

I understand it is more complex that I imagined given the cycling logic across similar events the script.
So regarding the wording for the documentation, I think the second bullet point (release mode) is easily understandable, but regarding the first one I am not sure I understood everything
.. especially this concept of "attachment" to press event. Does it mean that the next release action is the one following the last executed press instead of the normal flow of release events as is release mode ?

If it is the case, it raises the question of what happens if don't have perfect pairs of press/release events.
We might be a bit lost then, no ?

Have a nice day !

thx538 wrote:.. especially this concept of "attachment" to press event. Does it mean that the next release action is the one following the last executed press instead of the normal flow of release events as is release mode ?

Yes, that has always been the "normal flow".

thx538 wrote:If it is the case, it raises the question of what happens if don't have perfect pairs of press/release events.
We might be a bit lost then, no ?

"Press mode", if we call it that, has always been used for buttons. When I designed that mode a long time ago, I decided that the (press) event was the main event, and attached to that (quite literary in the code) was a potential (release) event.

When you press the button or dial, the next (press) command will be executed, and when you release it, the attached (release) command (if found) will be executed. If you don't have perfect pairs, all (press) commands will be executed, but if there are more (release) commands than (press) commands, not all (release) commands will be executed. That's the reason for having empty (press) commands to match (release) commands if you need to do something on the release but not on the press.

I'm sorry to bother you again, but it is still a bit confusing for me
.... So I tried a test case with this very simple requirement :

1. Initial state : without any press, a rotation will send a CC16
   
2. Secondary state: With one press (and immediate release without rotating) the next rotation will send a CC24. The following press (and immediate release without rotating) should revert back to the initial state of sending CC16.
   
3. From the initial state, pressing and rotating should send a CC24 and revert back to the initial state upon release:r
   
4. ... and the opposite when in the secondary state.
   

In short it is just a toggle, that can be activated either "on press/release" or temporarily and the design evolves accordingly.
You can ignore the return from DAW which works well.


I tried many combination but can't have it to work.
See the test script below :

Code:

Set State and design
[(init){minmax:1,24}{minmax:p,1,32}{@g_trsc:0}{design:#CONCAT(@g_dp, "TR_Selector.xml")#} ]
[(press)(@g_trsc:0){@g_trsc:1}{design:#CONCAT(@g_dp, "SC_Selector.xml")#}]
[(press)(@g_trsc:1){@g_trsc:0}{design:#CONCAT(@g_dp, "TR_Selector.xml")#}]
[(release:r)(@g_trsc:1){@g_trsc:0}{design:#CONCAT(@g_dp, "TR_Selector.xml")#}]
[(release:r)(@g_trsc:0){@g_trsc:1}{design:#CONCAT(@g_dp, "SC_Selector.xml")#}]

Rotate
[(rotate:1-24)(@g_trsc:0){cc:16,0,#@e_value#}]
[(rotate:1-32)(@g_trsc:1){cc:16,24,#@e_value#}]  

Return from DAW
Track : From DAW
[(init+)(cc:16,0,1-24){value:#@e_ccvalue#}{text:#@g_sname_sel#}] Arrives before name
[(init+)(@g_tname_sel:*){title:#@g_tname_sel#}]
Scene : From DAW
[(init+)(cc:16,24,1-32){value:p,#@e_ccvalue#}{text:#@e_ccvalue#}] Arrives before name
[(init+)(@g_sname_sel:*){text:#@g_sname_sel#}]



It works well for the cases 1/ and 2/ above (toggle with press+immediate release) but for case 3 the release event does not revert to the initial state.

Do you have any idea on how to make it work ?
Thanks for your patience.

thx538 wrote:It works well for the cases 1/ and 2/ above (toggle with press+immediate release) but for case 3 the release event does not revert to the initial state.

Do you have any idea on how to make it work ?
Thanks for your patience.

Since you have (press) commands, the plugin works in "press mode", meaning that (release) commands are attached to the preceding (press) command. Since both (release) commands come after the second (press) command, they will only be considered for execution after that (press) command. If you want to have (release) commands executed after the first (press) command, they must be defined after that (press) command:

Code:

[(press)(@g_trsc:0){@g_trsc:1}{design:#CONCAT(@g_dp, "SC_Selector.xml")#}]
[(release:r)(@g_trsc:1){@g_trsc:0}{design:#CONCAT(@g_dp, "TR_Selector.xml")#}]
[(release:r)(@g_trsc:0){@g_trsc:1}{design:#CONCAT(@g_dp, "SC_Selector.xml")#}]
[(press)(@g_trsc:1){@g_trsc:0}{design:#CONCAT(@g_dp, "TR_Selector.xml")#}]
[(release:r)(@g_trsc:1){@g_trsc:0}{design:#CONCAT(@g_dp, "TR_Selector.xml")#}]
[(release:r)(@g_trsc:0){@g_trsc:1}{design:#CONCAT(@g_dp, "SC_Selector.xml")#}]

Wonderful !
Thank you so much