OSC to Midi Newb Question
Howdy y'all,
So grateful for all the help I've received from this community & I hope I can be helpful myself one day...
Today (actually this past week) I've had trouble figuring out exactly how to convert OSC messages into Midi Messages inside of MAX.
So I've done some research and have learned to use "udpreceive" on port 8000 (for me) to receive the incoming messages from my iPod Touch using Touch OSC.
It seams to be working, I can see OSC Messages coming in on the "Max" window, but when I connect the "udpreceive" to any other node such as "unpack", "makenote" or the variable number node, nothing seams to be coming through...
I feel like there is a simple Newbie solution to this that I'm just missing, I haven't found any Forum topics concerning this specific issue yet, so any ideas on how to make this successful?!
Also I found a max patch that supposedly does what I'm looking to do except there are no instructions on how to use it:
I'm more looking to understand how to work this so I can create my own...
Thank you,
-AHEE
you can use the [route] object to filter and organize your OSC messages before generating your notes.
do [route /myoscmessagehere] to get specific messages out.
that should get you on/off messages out of the leftmost outlet, which you can feed into [noteout].
If in doubt, hook up a [message] or [print] to udpreceive - you'll see the messages coming in are not at all what you need to generate notes.
Thanks Wetterberg for the prompt response!
I tried using [route] object & still am having the same issue...
Maybe I just don't understand how to write [route /myoscmessagehere] properly... I'm brand new to Max ;) & to be honest I never used OSC before, but I'm determined to get this to work!
I've looked @ the reference help files, other threads on the forum, & google searches & am only more confused unfortunately.
Is it possible for someone to send a working example of [udpreceive] sending out ANY kind of data?! I'd be super appreciative & it would make my world so much better. Thanks.
The problem is that it really depends on what you're sending it...!
Hook up udpreceive to the right input of a [message] to see what's coming in. Or connect it to [print], whatever.
The OSC coming from touchOSC is unknown to me, but if it's, for instance, "/fader1/x 0.754" then you can do:
[route /fader1/x]
and you will get:
0.754
out of the relevant outlet.
I can't send you anything that preempts what's coming from your touchOSC setup, because I have no clue what you're transmitting.
Are you looking for something like this:
I feel we're getting closer to the solution! Thanks y'all. I'm beginning to understand how OSC works...
But still have same issue... we can make this work, ok.
So I'll be more specific:
I'm sending accelerometer data from Touch OSC on a iPod Touch and it comes into Max looking like this:
/accxyz
with the x,y, & z variables ranging between 1 and -1
Here are examples of 3 different ways I've tried to get this to work:
I very easily could be doing something wrong, but I still get no changes in the number boxes no matter what I've done, even while the Max print window is showing the changes flying by.
Any suggestions, recommendations, how can we make this successful?
Thanks
-AHEE
Entirely other question, how do I paste code? I tried copy/pasting it all in between the & also my Max doesn't have a Save As to Max Text, only Max Patcher, Max Help File, & Max Preset... Once I figure this out I can paste the code I said I would in my last response...
sorry :/
"Copy compressed" - you're not saving it, you're copying the code out.
fwiw:
[udpreceive "yourportnumberhere"] -> [route /accxyz] -> [unpack 0. 0. 0.]
This is pretty much the same info other people have been giving you, but FWIW:Example 24: TouchOSC data via wireless UDP
Just a heads up that o.route is preferred to osc-route by the folks at CNMAT (when it comes to creating their own patches) and is used almost exclusively.
o.route can do everything osc-route can do but it operates on the bundle itself, not just the output. So it doesn't matter how the original bundle was packed, o.route will preserve proper output order. Seems like a pretty significant difference.
Not to mention that it plays nicely with other o. objects and the library continues to be developed.
@metamax - can you expand on this? what do you mean by preserving output order / is there an example where o.route is preferred to osc-route?
@matias - Both o.route and OSC-route output received data through matching address outlets.
However, OSC-route is limited to reading the output of a bundle as a sequence whereas o.route operates directly on the contents of the bundle. As a result, OSC-route is dependent upon the order in which the data was bundled.. sending each message through its outlets in that order. This can result in undesired operation if the message order in a received bundled changes.
o.route will always be consistent with the order in which it outputs messages regardless of how the data is ordered in a bundle.
Here is an example of gating a message with both o.route and OSC-route. The same applies to any order-sensitive operation.