I'd like to hear your thoughts about what you want to see in a scripted dial.

I can see three different approaches:

1. Keep the current layout in the editor and add a "Scripted" option in each section's "Midi Command" dropdown. This may be a nightmare to implement, potentially having 5 scripts controlling the same thing.
   
2. Create a new "Scripted Dial" action where you reference a (single) script where everything is controlled. Like the Generic Midi button, the editor will probably have some fields for design and some other things. The script will have events and actions similar to the scripted fader button; events like "dial" and "tap", and actions like "lefticon", "righticon", and so on. There will probably be a lot of events and actions to control everything.
   
3. Create a new "Scripted Dial" action where you reference a script where everything is controlled. Period. This is an advanced alternative that allows you to create your own display design using the syntax defined in the Stream Deck SDK documentation. I don't know how to implement it, but the idea is to create your own JSON design file and then somehow reference the object names in the JSON file from the script. You would be able to do whatever you like with the dial display, but you would be entirely on your own.
   

The approaches are not mutually exclusive; I may eventually end up implementing all three if there is an interest in them. But initially, I want to hear what you think and if there are other scenarios I haven't considered.

There are 4 items now in the right menu area of the SD editor for Dials/Midi: Mackie Control, Generic Midi, Multi Midi, Multi Mackie.
I would leave these items as they are, adding one "Scripted Dial" item. So we would have the following items:

- Mackie Control
- Generic Midi
- Multi Midi
- Multi Mackie
- Scripted Dial

"Scripted Dial" could have an initial menu to select how to script the dial. As example, we could have the following options to start configuring the dial:

- Scripted Dial (Single)
- Scripted Dial (Multi)
- Scripted Dial JSON (Advanced)

This initial menu would also be useful to add options gradually (It could start with "scripted dial single" and when that configuration is finished start developing the next one, and so on).

Regarding the approaches you propose, I like the second and the third. I would start with the second one as it seems much easier than the third.

Regarding events and actions, I have got some ideas:

(press) (release): press / release the dial
(rotate:l) (rotate:r) (rotate:r,l):rotate the dial to left / rotate to right / rotate to left or right
(rotpres:l) (rotpres:r) (rotpres:r,l):rotate pressing to left / rotate pressing to right / rotate pressing to left or right
(tap:l) (tap:r) (tap:r,l): tap left screen / tap right screen / tap left or right screen
(untap:l) (untap:r) (untap:r,l): release left screen / release right screen / release left or right screen

{actionslike:_a_configured_event_}: this action would do the same actions defined in another event.

As example, the following script would send the same midi cc if the dial is pressed or rotated or the screen is tapped:

[ (press) {cc:1,1,1} ]
[ (tap:l,r) {actionslike:press} ]
[ (rotate:l,r) {actionslike:press} ]

I agree that "Scripted Dial" and "Scripted Dial Advanced" may be something to aim at. I don't dare think about what it would take to create a "Scripted Dial Multi".The Multi Dial uses 5 different JSON designs and close to 500 properties to control what is displayed...

I think starting with a simple scripted dial is a good starting point, and possibly the advanced version after that. When that is done, I can have an opinion of whether it is achievable to duplicate the simple scripted dial in some way to get a multi-dial or if the advanced version can take that role.

I'm not sure if a single action with a dropdown (single/advanced) or having two actions is the best thing. If I start with the single version, I think I can later see if having both in the same action will be complicated.

I think your suggestions for events and actions are a good starting point, but I find two suggestions troublesome.

The (untap) event is currently impossible since Stream Deck doesn't tell the plugin when you let go of the screen. Many developers have requested this, and Elgato seems to understand the benefit and will hopefully implement it in a future update of the SDK. Still, they have not made any official statement about this.

The {actionslike} thing, I would say, is not possible without a big change to the scripting language. It will, of course, be possible to have multiple (press) commands in a script, possibly as multi-event commands. The only usable way to have cross-references like that would be to add an ID section to each command and use that ID when referencing another command. I think that is overkill; it's easier to cut/paste the actions instead of referencing them.

What would you say is the most logical value associated with a rotate event? The dial is endless, and the plugin gets an event with a "tic" value: positive if turned clockwise, and negative if turned counterclockwise—a low value if turned slowly, and higher values when turned faster.

Either the plugin can forward those tic values to the script and leave it entirely to the script what to do with it. Or, I can implement something like the scripted fader button where the plugin is aware of the value range for the dial, calculates a value based on the number of tics (and some speed setting) and forwards this value to the script. Like the scripted fader button, the script must have an action to set the fader (or vpot) position so the plugin is aware of that position and can use that known position to calculate the move. The question is, though, whose responsibility it is to move the fader in the display...
I would say I probably prefer to forward the tic values and leave the rest to the script.

Agree with your opinion of "Scripted Dial Multi", {actionslike}, and the dropdown menu. The (untap) should wait until Elgato implements it.

Regarding the rotate event, I would like to understand better the "tic event" and how do you manage the tic values with the current midi dials.

Let's say that a {cc:1,1,*} is sent when rotating a dial.

I suppose that a tic of +1 sends the current cc value+1. What happen if the tic is +5 or +10? How do you increment the cc values? Do you have an scale?

And what is the maximum tic value, the faster one?

The tic logic isn't well explained in the SDK, but from my logs, I can see that if the dial is rotated continuously, the plugin will get an event every 50 ms with the number of ticks for that 50 ms. When you rotate the dial, you can feel distinct steps, and I assume that one such step is one tic, but that isn't documented anywhere.

The SDK doesn't say anything other than that a tic count of 0 can never exist (either it's positive or negative) and that it increases with higher rotation speed. Rotating it very fast seems to give a tic count of 10, but I don't know if that is the absolute maximum.

The current midi dial has a step property used when calculating the result of a rotation. If the step size is fixed (i.e., not zero), the fader is moved (ticks * step), and if the step size is dynamic (=0), the fader is moved (tics*tics).

For the script, I can see two alternatives:

1. The plugin reports a midi value; when the script sets the fader position, it should be a midi value.
   
2. The plugin reports tics; when the script sets the fader position, it should be in percent, not midi value.
   

The first alternative requires that the min/max/step properties are present in the editor so the plugin knows how to calculate a midi value from tics.
The second alternative has no such requirement but leaves all the calculations to the script.

Admin wrote:For the script, I can see two alternatives:

1. The plugin reports a midi value; when the script sets the fader position, it should be a midi value.
   
2. The plugin reports tics; when the script sets the fader position, it should be in percent, not midi value.
   

The first alternative could be managed directly from the script in the rotate event:

(rotate:LR,0,127,0)

The first order could be L for left, R for right, or LR for left and right.
The second, third and fourth orders are min/max/step.

Or with an action:

(rotate:LR) {step:0,127,0}

We could also have the min/max/step properties in the editor, and update them if the script changes it.

But I think the script must have the ability of changing the min/max/step properties.

The second alternative is a big enigma to me, as I can't imagine how the code should be if the plugin reports tics, and why the values must be in percentage.

Can you post a example code of how you imagine the 2nd alternative would work?

jordikt wrote:
...Or with an action:
(rotate:LR) {step:0,127,0}

An action is the way to go since events don't do anything; they only react to the input.

jordikt wrote:
Can you post a example code of how you imagine the 2nd alternative would work?

No. The more I think about it, the more I realize that it would be rather complex to handle in the script, so alternative 1 is the way to go. I will probably create an event reference variable with the tic info as well because it is needed if you have an endless knob where the only useful information is the rotation direction and speed, i.e., the tic info.

A reference variable with the tic info is a very good idea.

Agree that action for min/max/step is the way to go. I would separate the range and the step in 2 different actions:

[ (init) {range:0-127} {step:0} ]

Another action that can be very useful is to let the user make a formula for converting the tics to steps when the step is set to 0 (dynamic):

[ (init) {range:0-127} {step:0} {dynastep:tics*tics} ]

or

[ (init) {range:0-16383} {step:0} {dynastep:tics*tics*32} ]
[ (init) {range:0-16383} {step:0} {dynastep:tics*tics*64} ]
[ (init) {range:0-16383} {step:0} {dynastep:tics*tics*127} ]

I think this feature will be very useful if the range is set from 0 to 16383 (nowadays the step 0 for this range is not responding as good as for range 0-127).

Jumping into the discussion :

Admin wrote:I can see three different approaches:

It seems obvious that approach # 2 is the way to go.
#1 and #3. are too complex, for you or for the users.

Admin wrote:I think starting with a simple scripted dial is a good starting point

I agree, also considering that you can simulate some sort of multi dial with a button pile.

Admin wrote:

For the script, I can see two alternatives:

1. The plugin reports a midi value; when the script sets the fader position, it should be a midi value.
   
2. The plugin reports tics; when the script sets the fader position, it should be in percent, not midi value.
   

The first alternative requires that the min/max/step properties are present in the editor so the plugin knows how to calculate a midi value from tics.
The second alternative has no such requirement but leaves all the calculations to the script.

I think midi value would be more intuitive.
But, only given that min/max/step should be dynamic, considering that the object that a dial control may change over time (or upon reception of a midi message). So I do hope we will have something like {Min:} {Max:} {Step:}

Also, and as already discussed as part of the new dial scripting  capability I think we have the option to dynamically alter the translation as a dial collection of possible values and text : something that would replace the need for a translation file like:
{Translation: Value1, Text 1, Value 2, Text 2, etc. ...}

That would be very useful if we want to control rack devices and macro variations in Ableton Live, see example below of "dynamic" lists that change with the track selection :





... and also, but that is rather obvious, we should be able to dynamically change the text display (Fader or Vpot) based on a text variable and the value display (ex. DB, %, Number).

Finally, I think design options (in files) are sufficient as they are today (for fader and vpots). I have understood that they could be dynamically adjusted as well, sourcing the file name from a text variable, with something like {design:#@some_var#}

Thank you for your feedback on those points.
Have a nice day.

Thanks for your input.

thx538 wrote:It seems obvious that approach # 2 is the way to go.
#1 and #3. are too complex, for you or for the users.

#2 is prioritized. #3 is actually the easiest from the plugin's point of view since it leaves everything to the script. I agree that it is a very complex solution for users and will probably only interest a few, but on the other hand, it offers extreme flexibility.

thx538 wrote:I think midi value would be more intuitive.
But, only given that min/max/step should be dynamic, considering that the object that a dial control may change over time (or upon reception of a midi message). So I do hope we will have something like {Min:} {Max:} {Step:}

I agree that value is the way to go, and the script will be able to control min/max/step. The script will also be able to handle the tic values since an endless dial doesn't have values; it only has rotation tics.

thx538 wrote:Also, and as already discussed as part of the new dial scripting  capability I think we have the option to dynamically alter the translation as a dial collection of possible values and text : something that would replace the need for a translation file like:
{Translation: Value1, Text 1, Value 2, Text 2, etc. ...}

This is already possible using events that trigger on distinct values, so I can't see that a {translation} action adds anything to the script.

thx538 wrote:... and also, but that is rather obvious, we should be able to dynamically change the text display (Fader or Vpot) based on a text variable and the value display (ex. DB, %, Number).

Of course. My current plan is to enable scripts to control "everything", but reality will probably enforce some restrictions on what "everything" means.  

thx538 wrote:Finally, I think design options (in files) are sufficient as they are today (for fader and vpots). I have understood that they could be dynamically adjusted as well, sourcing the file name from a text variable, with something like {design:#@some_var#}

Yes.

Admin wrote:#3 is actually the easiest from the plugin's point of view since it leaves everything to the script. I agree that it is a very complex solution for users and will probably only interest a few, but on the other hand, it offers extreme flexibility.

I think it would be great if someday we can have this third approach implemented...