Running Average for jittering inputs


    Apr 22 2006 | 3:54 am
    Hiya, I was wondering if there was a good patch or object for smoothing jittering inputs?
    I have some capacitive sensors measuring distance of whose output has been converted to Midi. So the values go from roughly 5 - 124, but it is very difficult to get an exact value because it jitters by about 3 or 4 places up and down. Is there a way to smooth these such that only an incriment or decrement will happen if it is a great enough movement?
    Thanks - T

    • Apr 22 2006 | 8:29 am
      try [slide] wes
    • Apr 22 2006 | 11:07 am
      lp.stacey in "running average" mode.
      Trond has posted some patches using the object to good effect for exactly your purpose.
      Stacey is part of the freeware Litter Starter Pack. URI below.
      -- Peter
      -------------- http://www.bek.no/~pcastine/Litter/ ------------- Peter Castine +---> Litter Power & Litter Bundle for Jitter Heavy-Duty Mathematics for Everyday Use iCE: Sequencing, Recording & Interface Building for |home | chez nous| Max/MSP Extremely cool |bei uns | i nostri| http://www.dspaudio.com/ http://www.castine.de
    • Apr 22 2006 | 1:18 pm
    • Apr 22 2006 | 7:26 pm
      I've just had a look at the lp.stacey collcect statistics object, but it doesn't seem to work. . . I've tried banging the values 1, 1.5 and 2 but there is no output. Thanks - T
    • Apr 22 2006 | 7:29 pm
      Also i looked at the Trond Lossius website again, and am not sure which patch to look at . . .?
    • Apr 22 2006 | 10:24 pm
      On 22-Apr-2006, at 21:26, Tim wrote: > I've just had a look at the lp.stacey collcect statistics object, > but it doesn't seem to work. . . > I've tried banging the values 1, 1.5 and 2 but there is no output.
      OS, platform, version of lp.stacey? It's been tested previously on Max 3.7-4.5.6 inclusive, on Windows, OS X, and earlier Mac OSs and has so far never failed to work.
      The relevant bit (for your needs) of the help patch is the "run- stacey-run" subpatch.
      I will have to dig around the list archive to find Trond's patch, but it must be in there somewhere.
      Best -- Peter
    • Apr 23 2006 | 4:31 am
      Had another delve into Tronds stuff, still havent found the running average patch with lp.stacey object in it
      Had a look at the Slide list by Jasch, and its help file says its a slide lowpass filter for lists, ints & floats.
      Should the values on the output change when you adjust the settings at the top?
      Are there any better described patches? I really am a newbie and all this seems a little vague.
      It seems that even if i change the tl.velocity objects inputs there is no output change when playing with the values in the help file.
      Don't think i did anything weird with the installation. Any ideas? Thanks - T
    • Apr 23 2006 | 4:46 am
      have you tried slide? it's built in to max and has a help file that will work.
      wes
    • Apr 23 2006 | 10:29 am
      from the your questions it's hard to deduce what your seeing exactly.
      all of these smoothing filters work more or less on the same premise: they take an average of past values and and move the output value up or down according to some math based on that average.
      the [slide] object (i made my slidelist before there was slide in the standard distro) adds a fraction of the new value to the old value *AT EACH PASS*. if you input one value using a high dividing factor you'll get very little change. let's say you have a smoothing factor of 20, one twentieth of the new value get's added to the old value. when you start the old value is 0. so inputting a 1. will output 0.05. etc.
      > Had a look at the Slide list by Jasch, and its help file says its a > slide lowpass filter for lists, ints & floats. > > Should the values on the output change when you adjust the settings > at the top?
      there is one setting: the factor that goes to the right inlet (or is set using a typed in argument, or is input using the slide $1 message) all values going into the left inlet get filtered according to the smoothing formula.
      the slide-filtering works well for continous inputs, streams of numbers that continously change. you smooth out the data without loosing it's significant meaning. what you *DO* lose is precision in time. it takes a moment to reach a specific value (sometimes it NEVER reaches it, because of the averaging) for this it's important to have a continous stream. you can even force this by sampling the incoming values regularly with a metronome, even if your input is not continuous.
      hth
      /*j
    • Apr 23 2006 | 1:54 pm
      On 23-Apr-2006, at 6:31, Tim wrote: > Had another delve into Tronds stuff, still havent found the running > average patch with lp.stacey object in it
      Google turned up the following for the query "stacey trond site:synthesisters.com":
      The link includes a clever example for envelope tracking. The data smoothing is primarily handled by onepole~, stacey is primarily there to normalize data, providing an automatic calibration of the input signal.
      I'll include the patch below, which I modified to allow you to optionally use an instance of stacey as a secondary smoothing stage. Normalization is now based around the formula (mean + 3 * standard_deviation). Trond used a factor of two. Salt to taste.
      BTW, the Google query also turned up some messages from Trond with even more ideas for data smoothing. Thought you might want to know.
      Best -- Peter
      [Please cf the .sig from my previous post on this thread if you need it]
    • Apr 23 2006 | 4:03 pm
      Hiya, I've looked at Max and typed slide into an object box, But is gives me the message No Such Object. Doesnt this mean that it doesn't exist? Is the slide object not included in Max 4.3?
      T
    • Apr 23 2006 | 4:14 pm
      > Is the slide object not included in Max 4.3?
      no, it was released for the first time in Max 4.5, use [slidelist] instead.
    • Apr 23 2006 | 4:24 pm
      > Is the slide object not included in Max 4.3?
      or use this abstraction:
    • Apr 23 2006 | 6:48 pm
      I've had a look at the slide object in v 4.5.4 and it is actually a tilde object. - with a number~ output. which can then be converted back to a number (int) box. For midi communication.
      But i don't understand the slide up and slide down boxes in the help for the object, how do they work? Also the long list of messages that have been sent to me don't make sense? I'm a beginner guys!
      T
    • Apr 23 2006 | 6:59 pm
      "stacey trond site:synthesisters.com": this site does not exist. WHat was the link you were refering to? Tim
    • Apr 23 2006 | 7:05 pm
      On 23 avr. 06, at 20:48, Tim wrote:
      > I've had a look at the slide object in v 4.5.4 and it is actually a > tilde object. - with a number~ output. > which can then be converted back to a number (int) box. For midi > communication.
      slide arrives with 4.5.5...
      > But i don't understand the slide up and slide down boxes in the > help for the object, how do they work? > Also the long list of messages that have been sent to me don't make > sense? I'm a beginner guys!
      Slide up factor is used when the input value increases. Slide down for the decrease part. So there's a different smooth factor depending on the "direction" of the value.
      Bellow a version which have the same behavior as the slide object included since 4.55.
      HTH, ej
      save as myslide.pat
      save as myslide.help
    • Apr 23 2006 | 7:21 pm
      >"stacey trond >site:synthesisters.com": >this site does not exist. WHat was the link you were refering to? >Tim
      just enter
      > stacey trond site:synthesisters.com
      in google
      easy
      best
      kasper
    • Apr 24 2006 | 8:51 am
      Sorry for coming in late on this thread. The patch provided by Peter was something I made for a dance project. We were using the Diem Digital Dance sensor system, a bunch of bend sensors attached to the body of the dancer. Two of the problems we had were that the sensors had quite a bit of personality and could have good and bad days in term of what range they felt like outputting. In addition the sensors would tend to move a bit on the body during performance, so that the range of output might change during performance. For that reason I wanted to be able to auto-adjust the range and scale into a relative range (0.-1.) so that although resolution might vary, we would still be using all of the range 0-1. That way we wouldn't suddenly loose a lot of the range of the musical material if the sensors misbehaved. For that reason I asked Peter to make running mode for lp.stacey so that we could map incoming data to relative range based on average value and standard deviation.
      Alexander Refsum Jensenius has recently done the same thing and more as part of Jamoma (www.jamoma.org). jmod.autoscale autoscale input to a predefined range. It has several modes that might fit different needs.
      If you instead want to smooth incoming data but not change the range of it, The Ircam Phase-lib has a useful utility for it named "inertia". As I have been doing some modifications to the code, I am permitted to distribute it outside Ircam-forum according to a GNU LGPL license.
      The earlier post that Peter was referring to can be found here:
      Best, Trond
      Save as "inertia":
      Save as inertia-help: