[TouchOSC] How to format the data string for sending OSC msg (to mobile device)

Replies to This Discussion

Permalink Reply by Mirek on March 15, 2015 at 10:00am

I analysed what the UDP (OSC) component is sending.
Here is my result:
The red part shows whats happend when gHowl is sending an OSC msg.
Is this going to be fixed or is somebody still working on this plugin?

Best,

mirek.

Permalink Reply by Luis Fraguada on March 23, 2015 at 1:48pm

Hmmm.  I'll take a look at it.  That does not look right at all.  And I must admit, gHowl is in deperate need of a tune up!

Luis

Permalink Reply by Luis Fraguada on March 23, 2015 at 2:15pm

I just tried it and I did not get the same results as you.  /GH/none should not appear if you set  the address as you have done.  Do you have access to Processing?  I've attached a sketch (requires oscP5 library) and a gh definition.  I can receive the values from GH just fine.  Later I'll try on touchOSC.

Attachments:

• oscP5sendReceive.zip, 1 KB
• ghTestOSC.gh, 7 KB

Permalink Reply by Mirek on March 25, 2015 at 6:35am

After testing a bit with pluging and unpluging the information I also got good looking OSC msgs send (to localhost) receiving the msgs with pure data.

Unfortunately touchOSC (android app) didnt react on them.

(Just to see if my tablet is the problem I tryed the firefly osc sender, which actually worked fine. But to be honest, the way firefly is converting the msg you want to send is a bit unsatisfactory.)

Did you succeed with TouchOSC?

Permalink Reply by William Carroll on June 16, 2015 at 8:40pm

Hi Mirek,

I wanted to see if you ever solved this issue? I recently sank my teeth into TouchOSC/GH/gHowl/Firefly and seem to be experiencing the same problems that you faced when you first posted this message. I plan on hacking away at it for the next couple of days to see if I can get any results. Would love to collaborate on this with you. Let me know.

Permalink Reply by Jasper Drumm on June 17, 2015 at 1:19pm

I'm having similar issues. I can receive data into GH from TouchOSC no problem. But sending information back is another story.

I am trying to feed grasshopper data into a custom label on my OSC interface.  I've set up the UDP Sender similar to what Mirek shows above, and I've also tried Firefly's OSC Sender and various other ways of formatting the data before sending, such as concatenating the label address and data.  So far, nothing has worked.

It's beginning to seem like it may actualy be an issue with the label's preferences, as set up in the OSC Editor (see below).  I wonder if there is a specific way we need to set up the preferences in order for the label to accept incoming data.  This is just a theory, although playing around with it has not yet yielded any results.

Permalink Reply by William Carroll on June 18, 2015 at 8:28am

Here's a simple overview of my solution. I am not sure if I can provide a technical explanation of what's happening other than mentioning that when Grasshopper sends data, it sends the data itself as well as the name of the component from which the data came. Therefore, there is no need for prepending the directory of the TouchOSC element in the data itself (e.g. "/0/label1 DATA_GOES_HERE").

Sending text

Shoot the text through a panel first; right-click the panel; rename it to the TouchOSC label's name; connect that panel to the OSC Sender. Here's a screenshot of what this looks like:

Slider / Knobs / etc.

Similar principle applies here. That is, rename the object that connects to the OSC Sender to the same name as the element on your TouchOSC canvas. Another screenshot:

Hope this is clear and helpful. If this still doesn't work, try setting your TouchOSC page number to 0 using the desktop editor. I believe Firefly's OSC Sender defaults to 0 while TouchOSCEditor's default is 1.

Permalink Reply by Mirek on June 24, 2015 at 11:09am

Hello William!

The point within this thread is that we are talking about the gHowl method, which obviously works a bit different than the one of Firefly.

In my opinion gHowl does have a higher potential because you don't need to rename every knob and slider. Since this elements are missing an input its impossible to edit several parameters at the same time with Firefly. In contrast, this is possible with gHowl. But I didn't got it work yet - something seems to be wrong with some used libraries here.

Permalink Reply by William Carroll on June 24, 2015 at 2:09pm

Hey Mirek.

I fooled around with this some more today. Using gHowl components, I was able to receive and send data to-and-from Grasshopper and TouchOSC. Faders in my GH canvas would effect the faders within my TouchOSC interface. Check the definition below and see if it works for you.

Took a bit of time debugging (even though my solution shows a simple setup). For most of the time, however, I tried sending data to TouchOSC without gHowl's encoding algorithm (i.e. setting the Pattern parameter to '0' ASCII encoding). This yielded unexpected data -- a problem that is still unresolved.

If you pipe the data that you receive from TouchOSC in Grasshopper through a Python component with the contents:

a = repr(x)

as the code...you can start to gain a better understanding of the UDP data that is being sent between the listener and sender. Grasshopper panels, for better or worse, have a few metacharacters they natively recognize (e.g. '\x00' is a hexadecimal representation of an empty byte, which GH Panels don't display). This muddies the waters as far as debugging goes. It has tripped me up a few times now, so I am thoroughly in the habit of using the above, ad-hoc Python script. Good luck!

Attachments:

• gHowl_osc_sender_receiver.gh, 9 KB

Permalink Reply by Mirek on June 25, 2015 at 9:02am

Cool. Ill check that out in the next days!

Thx

Permalink Reply by Mirek on November 28, 2017 at 7:39am

After working on it for 2 years (just kidding) I finally got a way to get it work not using sliders but just normal number nodes. Any input goes into the Number Node which has to be renamed like the Object in the touchOSC editor but without prefix "/0/".

E.g. "/o/fader1" can be controlled by naming a number node "fader1"

(using firefly only here)