Valentin

I have pushbutton data coming in from TouchOSC . I have established communication, and can parse the messages, but can't seem to figure out how to throw out the messages that represent the a multi-button release state.

i.e. when a button is pressed it sends out /multi1/1 1. when released it sends /multi1/1 0.

I want to ignore any message that has the 0. at the end. I'm using the button as a trigger, and don't want to process double hits every time.

Is there a rexexp or something that will essentially discard the msgs that end in 0. ? Or am I looking at this the wrong way?

(I don't really want to use any externals to do this.. I already have the basic parsing down for most of the data coming in. It's just the pushbuttons... especially multipush. Wish I could just send a single message with them

i.e. when a button is pressed it sends out    /multi1/1 1.   when released it sends   /multi1/1 0.

Is there a rexexp or something that will essentially discard the msgs that end in 0. ?  Or am I looking at this the wrong way?

(I don't really want to use any externals to do this.. I already have the basic parsing down for most of the data coming in. It's just the pushbuttons... especially multipush. Wish I could just send a single message with them  

osc-parsing-simple-question-i-think

As you said you want to be external free, I guess you don't want to rely on osc-route.

If you use regexp to substitute the "/" with spaces, you can use the ordinary route object to parse the osc messages.

Then, why don't you simply use a "select 1" after all the routing? This way, each time the message is "1" (on), a bang is generated...

As you said you want to be external free, I guess you don't want to rely on osc-route.
If you use regexp to substitute the "/" with spaces, you can use the ordinary route object to parse the osc messages.
Then, why don't you simply use a "select 1" after all the routing? This way, each time the message is "1" (on), a bang is generated...


just include OSC-route etc in the standard Max distribution then, already

@mzed,
just include OSC-route etc in the standard Max distribution then, already
!


I recently started using the following(save it as "oscroute.js" and you can use it in place of OSC-route by using [js oscroute xxx xxx xxx]:

    var args = arrayfromargs(arguments);

        for(i = 1; i < jsargs.length; i++) {

            if(messagename == jsargs[i]) {

                outlet(i-1, args);

                matched = 1;

            } else if(messagename.indexOf(jsargs[i]) == 0 && messagename.charAt(jsargs[i].length) == "/") {

                outlet(i-1, messagename.substring(jsargs[i].length), args);

            outlet(jsargs.length-1, messagename, args);

                jsargs[i+1] = messagename;

                jsargs[i+1] = args[i-1];

            if(i+1 == jsargs.length-1) {

                i = args.length+1;

// oscroute.1.0
// James Drake
inlets = 2;
outlets = jsarguments.length;

The js thing is a full-on OSC replacement (actually I don't think it does all the funky things OSC-route can do, but it can do all the regular routing stuff).

OSC isn't just a protocol, it's a lifestyle.

probably using js is not the best idea for time sensitive stuff - if I understand correctly, the js object input gets deferred to the low priority thread. not sure about regexp...

probably using js is not the best idea for time sensitive stuff - if I understand correctly, the js object input gets deferred to the low priority thread.  not sure about regexp...


That could explain the laggy/spurty stuff I've been experiencing with my OSC devices....

Hmmm...
That could explain the laggy/spurty stuff I've been experiencing with my OSC devices....


There's this regexp solution, but I don't know if it suffers from deprioritization.

I'm going to pull all the js osc-route's from my patch to see if that works any better.

There's this regexp solution, but I don't know if it suffers from deprioritization. 

I'm going to pull all the js osc-route's from my patch to see if that works any better.


indeed that is the problem with the js solution. in fairness to james drake who wrote that js, i think he did so during max4 or max5 days, where it was possible to force js thread to high priority. in max6 alas no more.

regexp is possible but potentially messy.

cycling74 need to ask cnmat if they can have all the osc-route externals in the main distro. period. 10 years overdue.

Has there ever been an official comment as to why that's not the case? (like licensing or something)

I am completely sympathetic to having a default bias against third party objects. I've had to deal with all kinds of nightmare situations trying to find the objects in somebody's patch, get the right version, CFM vs PPC vs x86, students who can't edit file preferences in a lab, ispw compatibility, etc.

However, there are third party objects I use all the time. Percolate, Max Toolbox, jasch, Lobjects, cv.jit, Miller Puckette's... and CNMAT. In the case of OSC, these objects were developed by the same people who developed the protocol (OSC is from CNMAT). It would be nice if they were open source (some day...), but they are solid and trustworthy. The standard distro is just a starting point.

I am completely sympathetic to having a default bias against third party objects.  I've had to deal with all kinds of nightmare situations trying to find the objects in somebody's patch, get the right version, CFM vs PPC vs x86, students who can't edit file preferences in a lab, ispw compatibility, etc.

However, there are third party objects I use all the time.  Percolate, Max Toolbox, jasch, Lobjects, cv.jit, Miller Puckette's... and CNMAT.  In the case of OSC, these objects were developed by the same people who developed the protocol (OSC is from CNMAT).   It would be nice if they were open source (some day...), but they are solid and trustworthy. The standard distro is just a starting point.


I don't use any of the bells and whistles, so I'd be happy with just a version of route that took /this. Nothing fancy, just bread and butter stuff.

For me it's about ease of use/compatibility. I share all my patches, so the less the dependencies, the less users have to jump through hoops to use the stuff.

I don't use any of the bells and whistles, so I'd be happy with just a version of route that took /this. Nothing fancy, just bread and butter stuff. 

For me it's about ease of use/compatibility. I share all my patches, so the less the dependencies, the less users have to jump through hoops to use the stuff.


I've gone js and OSC-route free in my patch but each case requires a different solution. Some just using route, some regexp, some combinations.

+1 osc-route (or something similar) for inclusion.

I don't know about efficiency, but I came up with:

There's a regexp way to do it with one object (@replace " ", but I forget the first half of it).

just for the record, both methods side by side:

regexp seems to be a little slower (provided there is no error in my methodology)

Bummer....now I gotta change all my bits again....

I was away on vacation and missed all the responses - lol Thanks so much, and I will try OSC-Route when I have a moment to rework the parsing that I already did. If there's a chance it will be more responsive/quicker, I'm totally down for that! =)

I was away on vacation and missed all the responses - lol   Thanks so much, and I will try OSC-Route when I have a moment to rework the parsing that I already did. If there's a chance it will be more responsive/quicker, I'm totally down for that! =)

personnaly i used a combination of osc-route and regexp and run really good. sure regexp is more slowly than osc-route but take less cpu usage : route object "test" output to find the good. if you have a big route, object make lot of test...

with regexp is possible too to formate message to send directly the pass, and send any type of message without link. with lemur is best if your "formatting/scaling" value are good... you can write (on lemur) osc message corresponding to your receive...

OSC Parsing - Simple question (I think?)