May 28, 2012 at 3:35am


I am not really getting much understanding from the udpreceive help file but what i am trying to do is use touch osc to control the kslider through MIDI. I was using the Osculator program to transfer it from OSC to midi but I am trying to bypass using Osculator so TouchOsc sends strait to my patch and is then transferred to MIDI.


May 29, 2012 at 11:53pm

To clarify what I am trying to do. I am trying to receive OSC(open sound control) and convert it to midi (specifically control data).

May 30, 2012 at 12:50am

Use the CNMAT tools to process your OSC data


May 30, 2012 at 1:12am

Thanks ill try that.

May 31, 2012 at 1:36pm

the CNMAT tools seem like a pretty big hammer for this problem to me. (I’m sure they’re fine tools, but you can do this very easily with udpreceive and a handful of route objects.

Here’s a patch that receives on port 46000 (whatever your TouchOSC is sending), then looks for messages of the form “/PageName/ControllerName “. It converts them to MIDI controller 16 on channel 1. Pretty simple stuff. I’ve been using udpreceive for TouchOSC for a long while with good results.

– Pasted Max Patch, click to expand. –



May 31, 2012 at 2:00pm

Well, among the many nice features of the OSC-route object is the fact that you can just enter essentially exactly the same stuff that you see coming in through udpreceive to extract what you need.

Why would I use a “handful” of objects when I can use a single object? That’s like using assembly language when you have a perfectly fine high level alternative that works just as well (and in this case, it’s probably faster as well).

May 31, 2012 at 4:15pm

I think the benefits of OSC-route are rather cosmetic than functional.
For example, how would you get the numbers from addresses like /3/fader8 ?
Here is a simple solution with regexp.

– Pasted Max Patch, click to expand. –
May 31, 2012 at 6:00pm

An interesting feature of OSC-route is the ability to use the slash keyword in the arguments. It can be very useful for abstractions.


May 31, 2012 at 6:05pm

First of all, you’ll get no argument from me on the usefulness of regular expressions, they’re a life saver in many domains.

However, while your example makes it very easy to extract values out of the incoming string, what happens next? You’re going to have to add stuff at the other end to route to different places based on those address values. If you extract everything the same way, you’ll have quite an explosion in objects to handle all the different combinations. What happens when you need to detect faders, sendlevel, par(ameters) and so forth

On top of that, you’re still going to have to add
[route 1 2 3 4 5 6 7 8] to route the value of each fader to the desired place. The value of the OSC-route is that the routing is part of the object’s function.

It’s also a heck of a lot easier to see what’s going on. For example:

– Pasted Max Patch, click to expand. –
May 31, 2012 at 6:54pm

“The value of the OSC-route is that the routing is part of the object’s function.”

Good point. I’m convinced.


You must be logged in to reply to this topic.