phoenix

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?

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?

running-average-for-jittering-inputs

Trond has posted some patches using the object to good effect for 

Stacey is part of the freeware Litter Starter Pack. URI below.

Peter Castine +---> Litter Power & Litter Bundle for Jitter

Interface Building for |home | chez nous|

Max/MSP Extremely cool |bei uns | i nostri|

Trond has posted some patches using the object to good effect for  
exactly your purpose.

--------------    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

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.

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


Also i looked at the Trond Lossius website again, and am not sure which patch to look at . . .?

> I've just had a look at the lp.stacey collcect statistics object, 

> 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 

The relevant bit (for your needs) of the help patch is the "run- 

I will have to dig around the list archive to find Trond's patch, but 

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.

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?

Are there any better described patches?  I really am a newbie and all this seems a little vague.

Don't think i did anything weird with the installation.  Any ideas?
Thanks - T


have you tried slide? it's built in to max and has a help file that will work.

have you tried slide?  it's built in to max and has a help file that will work.

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 

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 

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 

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.

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.

> 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 

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 

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.

[Please cf the .sig from my previous post on this thread if you need it]

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.

[Please cf the .sig from my previous post on this thread if you need it]


Hiya, I've looked at Max and typed slide into an object box, But is gives me the message No Such Object.

Is the slide object not included in Max 4.3?

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?

> Is the slide object not included in Max 4.3?

no, it was released for the first time in Max 4.5, use [slidelist] 

no, it was released for the first time in Max 4.5, use [slidelist]  
instead.


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!

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!

this site does not exist. WHat was the link you were refering to?

"stacey trond 
site:synthesisters.com":
this site does not exist.  WHat was the link you were refering to?
Tim


> I've had a look at the slide object in v 4.5.4 and it is actually a 

> which can then be converted back to a number (int) box. For midi 

> But i don't understand the slide up and slide down boxes in the 

> Also the long list of messages that have been sent to me don't make 

Slide up factor is used when the input value increases. Slide down 

for the decrease part. So there's a different smooth factor depending 

Bellow a version which have the same behavior as the slide object 

> 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!

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.

>this site does not exist. WHat was the link you were refering to?

>"stacey trond
>site:synthesisters.com":
>this site does not exist.  WHat was the link you were refering to?
>Tim

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 

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 

The earlier post that Peter was referring to can be found here:

http://www.synthesisters.com/hypermail/max-msp/Mar04/10759.h

http://www.synthesisters.com/hypermail/max-msp/Jan04/9298.ht

http://www.synthesisters.com/hypermail/max-msp/Nov04/17763.h

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.

  http://www.synthesisters.com/hypermail/max-msp/Mar04/10759.h tml
  http://www.synthesisters.com/hypermail/max-msp/Jan04/9298.ht ml
  http://www.synthesisters.com/hypermail/max-msp/Nov04/17763.h tml

Running Average for jittering inputs