V1 features related to scripts and layout

Community Usage questions
1

open-stage-control has evelved a lot during these years, and I’m very grateful to you,
@jean-emmanuel, to be so open about implementing most of the features requested by users.
o-s-c is and has become incredibly powerful and flexible.

The automatic client sync, the availability on tablets and touch surfaces, the headless mode, the remote control features, are really cool.

Also, clone widgets, matrices, variable inheritance, allow to do really complex things without too much copy/paste.

And there are solutions for every problem, even very complex ones.

I also see a list of very interesting features in thre upcoming v1, like hidden script widgets, notifications, class and style attributes in html widgets,
url-options applied on remote browsers, button tap mode, native setTimeout handling…
The future looks great!

With all the experience I had during these years, here is a list of
additional features I would find very helpful and that would ease the use
of o-s-c, at leat in my case.

@jean-emmanuel, and others, feel free to discuss about them or tell if they would be useful for you too.

Almost all featuress I think about are related to the script widget.

Because when we need to do complex things or do things in a programmatic way, it
is somewhat tedious to have a separate script widget for every button/fader/…

We have to create the script widget, hide it somewhere, and also remember that this script is trigger by this particular button
(partiually addressed by this feature in v1: ‘always hidden except in project tree’)

It would be nicer to have a ‘script’ field in each widget, and be able to handle a received value in a programmatic way.

It would also be helpful to compare the received value to the previous one, like:
if (value != previous_value) {…}

Also, it would be great if the script function was called even if the value hasn’t changed, without using the linkId property

we could also imagine, a bit like in visual basic, that a function would be called automatically, like on_fader1_change(), on_fader1_receive(),
on_fader1_clicked(), etc

If these functions were located in a separate script file, this would ease using versioning, diff tools and such

It is a bit what is done with custom modules, but a bit more integrated.

And a last useful feature would be to have access to set(), get() etc, to
easily ‘sync’ a value between widgets (there are tother ways to do it currently but sometimes it requires
a more complex workflow)

For instance, if you have 4 buttons and a text, and that you want to display a text depending on the last button pressed, you have to write this in the text widget value:
@{btn1}?@{btn1}:(@{btn2}?@{btn2}:@{btn3})…

This could be replaced with set(text, this.value) in each button.

Also, for what I see in the screnshot, the upcoming v1 looks very nice!

tree-lieke widget hierarchy seems really useful, and overall o-s-c looks much nicer!

I think the upcoming layout will involve a lot of mouse movements between the left and right part of the screen, except if panels are dockable.

Could you also consider having multiple windows ? that would also allow easier editing with multi-monitor setups

@jean-emmanuel I can split all this into separate features on github, or add more use cases, but this is only a preliminary discussion.

Thanks for taking some time to review/criticise this :wink:

2

Thanks for your your feedback and thoughts on v1 :slight_smile:

I'm currently trying to implement this and it looks promising, under the hood every widget could host a script widget feed with its script property... power !

It would also be helpful to compare the received value to the previous one, like:
if (value != previous_value) {…}

The locals variable will let users store the value to compare it later if needed.

Also, it would be great if the script function was called even if the value hasn’t changed, without using the linkId property

I guess the script property would solve that too.

we could also imagine, a bit like in visual basic, that a function would be called automatically, like on_fader1_change(), on_fader1_receive(),
on_fader1_clicked(), etc

Things are really not heading this way for now, I'm not planning to expose more events for the existing widgets. Something like Lemur's canvas could open that door but I havent made much progress on this one (although I've started something...)

If these functions were located in a separate script file, this would ease using versioning, diff tools and such;
It is a bit what is done with custom modules, but a bit more integrated.

Not planned for now.

And a last useful feature would be to have access to set(), get() etc, to
easily ‘sync’ a value between widgets (there are tother ways to do it currently but sometimes it requires
a more complex workflow)

set() and get() will not be added to JS{{}} block's scope. Scripts (standelone or built-in) is the way to go.

For instance, if you have 4 buttons and a text, and that you want to display a text depending on the last button pressed, you have to write this in the text widget value:
@{btn1}?@{btn1}:(@{btn2}?@{btn2}:@{btn3})…

Currently you can solve this by linking all these widgets to a script with a master linkId (>> id) and let the script do the magic.

This could be replaced with set(text, this.value) in each button.

It could be done this way too with built-in scripts

I think the upcoming layout will involve a lot of mouse movements between the left and right part of the screen, except if panels are dockable.

Panels are not dockable although they can be resized or hidden, the ui components are pretty barebones so it's not possible at the moment. However, using the tree is not mandatory, I haven't suffered much from mouse movements yet, I guess we'll see.

Could you also consider having multiple windows ?

It's not possible without rewriting many things and I'm not convinced it's worth the effort to be honest.

3

thank you for your remarks and precisions!

set() and get() will not be added to JS{{}} block’s scope. Scripts (standelone or built-in) is the way to go.

builtin scripts are (will be) a cool feature!

if we can use set() and get() inside built-in scripts, this is great already!

Currently you can solve this by linking all these widgets to a script with a master linkId ( >> id ) and let the script do the magic.

You're right.

btw, will there be a way to somehow see the dependencies between objects?

or at least have a 'verbose' mode where we could read:

  • widget xx reacted to event xx on widget yy?

or

  • widget xx received OSC value yy ?

it could be useful for debugging

thx

4

Hi @cyberic,

I’ve been enjoying OSC for some time now, and have total respect for @jean-emmanuel . I use OSC quite basically, although I do have a custom module running. I was just wondering, the stuff you talk about, I’m not sure I understand what you want to do with OSC. Would you mind going into some detail regarding how you use OSC now, and what the v1 scripting updates would mean for you? That would help me understand the power of the software I think too.

And if you could explain it a little more in basic terms, that would be great too!

Cheers.