The missing parenthesis is obviously a typo, thanks for noticing.
I will be back from a small easter holiday next friday, so if someone wants to test, please replace that ruleset with the version located here)
Btw: that gist above is using the new output format, where multiple lines of text are declared with [[double square brackets]]. To me, this seems much more readable, and you can copy/paste functions without having to replace /n linebreaks. I have found that 'mining' rulesets for functions is quite useful, and this little change makes it so much easier...
I have examples that react to an OSC message, but the associated function gets invoked three times.
Weird, are you sure you're not mistaking number of invocations for the value itself (it comes with three parts) ?
Perhaps I have probably overlooked something... You know, TouchOSC sends out a constant stream of messages so it's quite easy for a detail like that to get drowned out in all the noise. But while testing with my monome, I am pretty sure that this didn't happen.
Edit: I just checked - if I disable tilt sensor (to avoid drowning in data) and just look for a basic pattern such as a pressed button, things work as they should.
Makes me wonder if you tested this with a similar source - TouchOSC on iOS?
Another thing that I would like to hear your opinion on (or someone else who works with OSC on a regular basis):
Right now, an OSC input pattern can specify the "pattern" and "values", with the latter being able to use wildcards or literal values. It's nice and flexible, but often, you also encounter a bunch of patterns that are so similar that it would be nice to be able to apply wildcards to the pattern itself.
For example, the TouchOSC layout called 'Simple' defines a number of buttons on the second page as having these paths: /2/push1,/2/push2,/2/push3 and so on...
When pressing one of these buttons, the first value is set. For example
So, while you could create a condition for each of these patterns, the xRules UI would get quite crowded. And even if we are talking about just 16 buttons, it's a repetitive task that no-one would enjoy (as a sidenote, Duplex doesn't have this problem, as we are using control-map files)
A simple solution would be to allow wildcards as part of the pattern (the path-like segment), and then capture whatever value is specified there.
-- capture button index and state
I considered making it an asterisk style wildcard. But I think it's good to be as specific as possible - the pattern above is specifying an integer value, so it wouldn't accidentally capture a pattern like /2/push/more.
Another reason it's good to be specific is that, with integer values xRules can improve response time by caching the results.
Edited by danoise, 26 March 2016 - 12:17.