non-temporal smoothing/jitterKill

    Jan 27 2011 | 3:32 pm
    Hallo chaps/-esses
    I'm having a problem with my signal conditioning: a resistive touchscreen is sending X/Y location data via Arduino to Max. The circuit and Arduino code is optimized, with one minor/major snag - tiny variations in fingertip contact pressure create radical leaps in that data. In order to get 'smooth' predictable values into Max one must maintain continuous pressure, and contact/release must be instantaneous; anything else and my X/Y [pictslider] leaps about all over the shop.
    I have been successful in optimizing the hardware and code (through the Max, Arduino and Instructables forums), but the jittery characteristic of this type of touchscreen remains. My question is this: I know what my pseudo code is, which objects are best suited to realise a non-temporal "jitta-killa"? There are numerous solutions using [line], [if], [gate] etc on the forum but most introduce unwanted latency (however small):
    pseudo code
    "if the value makes a sudden large leap DOWN, ignore that large leap and retain the value before that leap, regardless of number-stream direction".
    This is only really vital when values are continuously scrolling (ie during continued contact).
    I'm halfway there with this algorithm:
    [number] -> [t i i] ->-> (L, R)[>] -> [sel 1 0], which gives me number-stream direction........
    This feels a little poorly-explained,

    • Jan 27 2011 | 4:48 pm
      Ahoy, can you define the threshold above which you would call a leap large?
    • Jan 27 2011 | 5:19 pm
      there is a "look before you leap" in the cnmat collection. from the helpfile:
      Look Before You Leap:" Echo an input stream of numbers to the output, but "don't believe" large jumps unless the input stays at that value for a while.
      does that help?
    • Jan 27 2011 | 5:44 pm
      this is tricky, as the interface will be used in two ways: drag single finger 'continuously' or touch discretely (single finger too); this last will create large leaps that are intended. Discrete touches create almost instantaneous jumps to the required/intended value; with dragging/scrolling, however, variations in finger pressure create the sudden (but not instantaneous) leaps to a much lower value. Imagine drag-clicking and discrete clicking; this is the functionality i'm intending. The touchscreen is not pressure sensitive, it's just doing simple X/Y polling - it's the minute changes in fingertip touch area that create this anomaly.
      I will definitely check the cnmat library and get back here with the results
      Thanks all
    • Jan 27 2011 | 6:45 pm
      There was a thread on smoothing a couple of years ago wherein several approaches were presented:
      Perhaps one of them can be modified to your needs.
    • Jan 27 2011 | 9:26 pm
      Cheers Chris
      A patch that resides in my 'Max utilities' folder contains many jitter/noise solutions, several of which I think are yours. I'll look at the various solutions in the thread you mention.
      My own attempts all produce some degree of latency (even those involving just [zl] objects, or audio rate filtering) - I guess because they are ON all the time (thereby inducing latency), I'm looking for something that responds only if certain conditions are met, for example:
      if the number stream is smooth and without large leaps, let it go, if a large leap occurs ignore it; if the number stream is static and a leap occurs don't ignore it.....
      feature request pseudo-code compiler object for Max?
      Thanks again
    • Jan 28 2011 | 3:11 pm
      For those following:
      [zl stream 5] -> [zl median] appears to be the best solution thus far; but only for a continuous (scrolling) number stream - if the number stream consists of discrete values (via discrete touches), for example (X=45, Y=45) then (X=126, Y=5), [zl stream] can't do its job. I tried inserting a pack/line combo, but that has the inverse effect. Discrete values get through, but jitter returns?!?
      cnmat's [lbyl] works quite well too, but exhibits similar functionality when discrete values arrive......
      here's an annotated patch: