algorithmic modeling for Rhino
Im tyring to send a correct data string to TouchOSC on my android (kitkat).
So far I have a working communication in both direction (the status signal of TouchOSC at least is showing it).
Getting OSC msg from TouchOSC to GH works perfect.
Sending OSC msg to TouchOSC device in contrast is not having an effect on the TouchOSC "faders" or "LED"s (except showing that there is some kind of incoming data with the status signal).
So Im wondering how to format the data string to be sent?
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!
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.
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?
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.
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.
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").
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.
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.
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!
Cool. Ill check that out in the next days!
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)