Cloning, pasting, decoupling widgets, send recevie

[johan]

Hi, new here. Couldn't find answers to these, so decided to ask.

• What's the difference, in terms of resources and performance, between cloning and pasting (or rather pasting id + 1)?

• Do i understand the intent for/difference between cloning, cloning + parameters overriding and copy-pasting (id + 1) correctly as a continuum: if you want to have similar widgets, but completely decoupled, without recreating it, you use paste id + 1; if you want to have complete coupling, you use cloning and if you want to have something between - like same look, but reacting to/sending different osc messages, you use cloning + parameters overriding?

• How is the decoupling actually done? Or rather, how is it done fore composite widgets? I'm able to decouple simple buttons overriding id parameter in props - though it's kinda confusing: now the cloned widget has it's own id parameter & widgetId parameter (for coupling) - which makes sense, but you also have to specify another id in props to decouple it's value on top of specifying value parameter in props, which makes it complicated to me. Wouldn't it suffice to just set the value in props? Btw., what does this mean: " * If they share the same id : in this case, the synchronized widget doesn't send any osc/midi message. This case is mostly used for widget cloning." - it's taken from documentation; what id does it refer to? The one set in widgets settings or the one in props? Or?

• What's the difference between send and receive functions in custom modules? It seems they both are sending messages to client widget, which is bit confusing. I've also seen sendOsc and receiveOsc (or something like this), but didn't try them. What's their purpose and difference compared to send and receive?

Btw, i like OSC - looks quite capable, just having some overall picture of it's components, their purpose and relations would really help. Thanks.

[jean-emmanuel]

@johan

• What's the difference, in terms of resources and performance, between cloning and pasting (or rather pasting id + 1)?

There's almost no difference, clones are a tiny bit more expensive but it shouldn't be noticeable.

• Do i understand the intent for/difference between cloning, cloning + parameters overriding and copy-pasting (id + 1) correctly as a continuum: if you want to have similar widgets, but completely decoupled, without recreating it, you use paste id + 1; if you want to have complete coupling, you use cloning and if you want to have something between - like same look, but reacting to/sending different osc messages, you use cloning + parameters overriding?

Sounds about right !

I'm able to decouple simple buttons overriding id parameter in props - though it's kinda confusing: now the cloned widget has it's own id parameter & widgetId parameter (for coupling) - which makes sense, but you also have to specify another id in props to decouple it's value on top of specifying value parameter in props, which makes it complicated to me. Wouldn't it suffice to just set the value in props?

The value property is not always set, I don't think we can do without overriding the id manually. I admit it's not simple but on the other hand it offers a lot of flexibility.

Btw., what does this mean: " * If they share the same id : in this case, the synchronized widget doesn't send any osc/midi message. This case is mostly used for widget cloning." - it's taken from documentation; what id does it refer to? The one set in widgets settings or the one in props? Or?

id refers to the id property (2nd property in the inspector). What's hard to see here is that clone widgets are wrappers around the actual cloned widgets, here's a small diagram that illustrates it:

how is [decoupling] done fore composite widgets?

The common pattern for this in o-s-c it to define a set of arbitray variables in the container's variables property and override them using the props property of the clone widget. Check out clones_and_variables.json in this repository: in the original composite widget, ids are all post fixed with a variable that can be overridden by the clone.

What's the difference between send and receive functions in custom modules? It seems they both are sending messages to client widget, which is bit confusing. I've also seen sendOsc and receiveOsc (or something like this), but didn't try them. What's their purpose and difference compared to send and receive?

send() sends an osc/midi message outside of open stage control. receive() sends a message to the clients, as if open stage control had received it. sendOsc() and receiveOsc() are older equivalents to send() and receive() with a less effective syntax, these are no longer documented and shouldn't be used (although they still work for compatibility reasons).

[johan]

Wow. That was really quick thanks.

@jean-emmanuel

There's almost no difference, clones are a tiny bit more expensive but it shouldn't be noticeable.

You mean the clone widget wrapper, right? Just curious

@jean-emmanuel

id refers to the id property (2nd property in the inspector). What's hard to see here is that clone widgets are wrappers around the actual cloned widgets, here's a small diagram that illustrates it:

Ok, so when i override the id in clone widget (the wrapper) props, i actually change the cloned widget's id, right? Btw. i think something like this diagram in documentation could be beneficial for new users (maybe in some "advanced/internals" chapter, to not scare some people). But maybe it's sufficient here.

@jean-emmanuel

The common pattern for this in o-s-c it to define a set of arbitray variables in the container's variables property and override them using the props property of the clone widget. Check out clones_and_variables.json in this repository: in the original composite widget, ids are all post fixed with a variable that can be overridden by the clone.

Thanks for the example. I actually found it, and tried to replicate it, but just from looking at the json file in git, and probably made some mistake somewhere, cause it didn't work. Will try to look at it more thoroughly. But what confuses me now is why is there no id overridden in clone widget's props?

@jean-emmanuel

send() sends an osc/midi message outside of open stage control. receive() sends a message to the clients, as if open stage control had received it. sendOsc() and receiveOsc() are older equivalents to send() and receive() with a less effective syntax, these are no longer documented and shouldn't be used (although they still work for compatibility reasons).

I guess i'm using the send wrongly then I use it in oscInFilter to send message to my OSC client. Like this (8080 is osc port set via -o option, /loop0_mute is a button):

send("localhost", "8080", "/loop0_mute", "0")

Is this wrong? Should i use receive instead? I also use recevie in the module, like this:

receive("/loop0_state/value", loop_state)

/loop0_state is a text field and loop_state is a variable holding string for the /loop0_state widget.

The send kinda updates widget indirectly (switching the button to off by sending it 0, which is value in it's off state) and receive directly (it's value) in my case - i was just trying pieces of code i found here or in the documentation. Anyway, since it seems to work - using send to send message to my OSC client - does it mean send and receive are identical? Is there some other difference?

[jean-emmanuel]

@johan

You mean the clone widget wrapper, right? Just curious

Yes, clone widgets add a small overhead by wrapping the actual cloned widget.

Ok, so when i override the id in clone widget (the wrapper) props, i actually change the cloned widget's id, right?

Yes

But what confuses me now is why is there no id overridden in clone widget's props?

This is because in this case I did not think it was necessary to make the panel's id unique, but of course you can override it in the clone's props.

send("localhost", "8080", "/loop0_mute", "0")

Is this wrong? Should i use receive instead?

Yes, using send here only makes the message take a longer road (you're sending to o-s-c input port), plus it will be processed by the custom module's oscInFilter() function. receive() goes straight to the clients.