OSC Parsing - Simple question (I think?)

    Aug 26 2012 | 11:12 pm
    Hi All,
    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

    • Aug 27 2012 | 4:13 am
      No need for regexp, this should work
    • Aug 27 2012 | 1:55 pm
      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...
    • Aug 28 2012 | 6:08 pm
      Just use OSC-route already.
    • Aug 29 2012 | 10:42 am
      just include OSC-route etc in the standard Max distribution then, already
    • Aug 29 2012 | 3:27 pm
      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]:
      // oscroute.1.0
      // James Drake
      inlets = 2;
      outlets = jsarguments.length;
      var jsargs = arrayfromargs(jsarguments);
      function anything() {
      var args = arrayfromargs(arguments);
      if(inlet == 0) {
      var matched = 0;
      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);
      matched = 1;
      if(matched == 0) {
      outlet(jsargs.length-1, messagename, args);
      } else if(inlet == 1) {
      for(i = 0; i if(i == 0) {
      jsargs[i+1] = messagename;
      } else {
      jsargs[i+1] = args[i-1];
      if(i+1 == jsargs.length-1) {
      i = args.length+1;
    • Aug 29 2012 | 5:33 pm
      does my thing not work?
    • Aug 29 2012 | 5:38 pm
      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).
    • Aug 30 2012 | 4:34 pm
      OSC isn't just a protocol, it's a lifestyle.
    • Aug 30 2012 | 6:29 pm
      osc-route +1
      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...
    • Aug 31 2012 | 12:03 am
      That could explain the laggy/spurty stuff I've been experiencing with my OSC devices....
    • Aug 31 2012 | 12:56 am
      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.
    • Aug 31 2012 | 8:27 am
      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.
    • Aug 31 2012 | 4:57 pm
      Has there ever been an official comment as to why that's not the case? (like licensing or something)
    • Aug 31 2012 | 9:11 pm
      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.
    • Aug 31 2012 | 10:52 pm
      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.
    • Sep 01 2012 | 3:35 pm
      Good news! route does take /this:
    • Sep 01 2012 | 4:52 pm
      Only for very specific usages.
      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.
    • Sep 01 2012 | 5:25 pm
      +1 osc-route (or something similar) for inclusion.
      I don't know about efficiency, but I came up with:
    • Sep 01 2012 | 7:00 pm
      There's a regexp way to do it with one object (@replace " ", but I forget the first half of it).
    • Sep 01 2012 | 9:02 pm
      just for the record, both methods side by side:
      regexp seems to be a little slower (provided there is no error in my methodology)
    • Sep 01 2012 | 10:40 pm
      Bummer....now I gotta change all my bits again....
    • Sep 04 2012 | 1:51 am
      Hi All,
      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! =)
    • Sep 11 2012 | 12:46 am
      hi all
      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...
      a simple exemple :