XR18 OSC Example

As soon as the relationships with direct access were actually explained…it worked immediately
For a new user, the documentation is fairly black

Ultimately the definition is in context to fixed schema hosts ie XR18 using native widgets is something like this (please correct):

In fixed schema hosts:

1. A widget can use a control a remote mixer element but it can only do so using direct addressing which is mentioned in the manual and is switched on per widget. Its actual use, impact on outcomes and example of its requirement for fixed schemas is not.

2. The UI has mixed fields and the OSC address is actually an editable field despite not being indicated

3. The widget handle which is editable only applies that name to the end of the reference and therefore cant be used to make any path name ie it doesnt serve any purpose in bidirectional comms.
ie adds a target path but inserts it as a hardwired token and then appends /setvalue
Its use as a handle for internal reference is however plain but it vague because the non directional split of use ie OSC vs Internal is not obvious. You cannot use it for direct address return path etc even though it has a non editable path displayed beside it in an OSC context

4. The xr18 ip address is simply entered into the target IP field and the port of the xr has a fixed number of 10024

BUT…

There is no way to sync the widget to the remote element without scripting

So the overview is

The bottom line is that the widget/ui gives a taste of the possibilities but cant actually deliver meaningful bi directional control; anything useful in this context must be done via scripting.

Hope that helps someone else…hehe that was like pulling teeth tbh but the fragmentation of help data, coupled with the inconsistencies in the ui makes you feel very blind when you are stepping fresh into this world; its a lot of energy to invest…its of course second nature when you have years behind you…

Thanks to the forum help