Im wondering whether anyone might have even a very simple example of controlling a parameter as per above (or similar)?
That would be a helpful resource; Im definitely only looking to control some iem sends for a couple of channels but would be an amazing example of GP in action…(circled in red here)
Thanks
The list of X Air OSC commands and howtos can be easily found on the web. Here is a list of X Air OSC commands I pulled from the web
XAir-OSC-Commands.pdf (32.3 KB)
Thanks for that; i had a couple of different info sheets but that one is quite comprehensive
I was intrigued to see if anyone was using GP in the same way as i was thinking…ive found other peoples examples a great way to grab the concepts and get to the point; tbh i had not found a control surface previously, that was adept enough to make it worthwhile and this little iconpad is full of surprises despite the quirkiness.
The gig file and resources shared by the community have been really helpful but couldnt see any obviuos simple examples.
A simple step by step guide would encourage new users of osc in GP context 
Cheers
Im pretty confused here
There are lots of commands to talk to GP
There is a midi out osc module to send midi commands…but I need to do a setvalue to a targ param.
There are example blogs etc but they are all controlling GP? I need GP to control the xr
But how do you send osc out from a widget to the xr/osc host?
I have enabled OSC in GP
set the target ip (in this case 192.168.0.254)
Hardwired client port of 10024
Enabled OSC on the widget but that seems a handle to access not drive data?
What next? Where is the addressing path set for the client?
Sorry if it sounds really dumb but I must be looking in the wrong place or something…this is the missing info Im talking about…there is just nowhere to start in relation to GP controlling something that I can see
Take a look at this post.
In the Script you will find functions to build and send OSC messages.
The default implementation in GP has a fixed format for the OSC address, based on the widget handle, which adds ‘SetValue’ to the address.
My understanding is that if your target has its own defined address requirements, then you can’t use this and must instead use the ‘Direct Addressable OSC’ section:
Using a free OSC monitor like Protokol is also very helpful to confirm what is being sent out.
Yep that is straight forward
Aha! Well that would be the missing bits for me.
Well that is super simple to send out…when you know how
BUT
How do you get feedback to GP from the mixer?
But m4l is the manager right? Im not using max…just simple GP > xr18
CHeers
GP is sending messages to max and in scripting you can see how to define such custom addresses and how to send it to specific ports and ip addresses.
This has nothing to do with max.
With direct OSC access you can define the OSC address to be used when a widget is moved.
But when you need multiple messages to be sent when the widget is moved ou need scripting.
When using the ‘Direct Addressable’ I’m not actually sure about syncing with incoming messages (as I only use the default option using the widget handle).
If you get stuck, scripting can of course do everything 
I think with direct OSC access syncing is not available.
The good old OSC callback can help 
Yeah, at some point we might add bidirectional management to the direct access stuff but it’s a little bit of a pandora’s box for various reasons so low priority, particularly since one can leverage GP Script for these kinds of things.
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
Cheers…I could only see the code in the rackspace which is sending only. There doesnt seem to be any polling or bidirectional; its relying on system events?
There is a OSC callback available.
When you are in scripting window you can include a code framework.
Ok thanks…Ill have a look at that…hopefully get back to doing music at some stage…I have quite a long beard now jokes!
Now I know that ie scripting is the only way I can continue on the journey…I would have gone straight there if I didnt see clues in the ui that indicated otherwise… thats for sure
You are reading too less….
Take a look at the scripting documentation and function list.
