Rmrlife021402

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.

udpreceive

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).

Use the CNMAT tools to process your OSC data

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.

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.

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).

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).


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 ?

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.


An interesting feature of OSC-route is the ability to use the 

 keyword in the arguments. It can be very useful for abstractions.

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

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:

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:


"The value of the OSC-route is that the routing is part of the object's function."