Smoothing out numbers
Hello,
I'm just a newbie with Max/msp, and trying to figure out something.
I'm working with the wiiRemote in max/msp by using the tk.wii.
The output data of the axes of the Wiimote are, how shut I put it, very nervous and not stable. The data is not steady even when I'm holding the Wiimote still (just lying it on the table). What I want is to get steady numbers.
For example. the output is just jumping from 51-50-51-49-50-52-51-50 etc. And I just wane to have the number 50 as output, so the numbers 51-52-49 are just forgotten. And when the number is close by 55 the output have to shown 55 en not 53-55-54-53-55 etc. Clear?
Is there a solution for my problem. Could somebody give me a hint/starter of something. I don’t know how to begin.
Thank You
Nicolette
my guess would be that u need to average the values, but it could also be that the wii remote is not properly calibrated...
as a starting point, u should look at the "sensor-tamer.maxpat" abstraction, which u will find in the extras menu / examples overview (max 5 only).
hth,
j
Try doing a search for hysteresis which may give you a starting point. You could try using objects such as 'change' and 'timer' for doing things like debouncing.
I'd say you could start by looking up message-domain lowpass filterings
-using [line] as a filter thanks the ramp time basically : sending
input values to a simple [$1 200] message going to a [line] object,
the longer duration, the smoother output)
-you could also convert your input stream to signal and lowpass it,
then sample it back to message domain.
-otherwise Tristan's library has a ready-made filter called
[smoother] ...
then if you need values to stick to specific intervals I would
downscale the input to the total number of intervals and then upscale
it back to your output range. Like if you want values to stick to
5-10-15-20-25-30 etc. with an input range of say 100 , you could map
the input from 100 to 20 and then map it back to 100. With the line
at the output you'll get a smooth ramp but values would stabilize on
5 - 10 -15 etc.
The tricky part is then both to keep something responsive enough,
it's always a delicate compromise with filtering.
im not either a huge master in programming so please someone correct
me if im saying crap.
but that should work.
O.
On 28 juil. 08, at 14:54, Nicolette wrote:
>
> Hello,
>
> I'm just a newbie with Max/msp, and trying to figure out something.
> I'm working with the wiiRemote in max/msp by using the tk.wii.
> The output data of the axes of the Wiimote are, how shut I put it,
> very nervous and not stable. The data is not steady even when I'm
> holding the Wiimote still (just lying it on the table). What I want
> is to get steady numbers.
> For example. the output is just jumping from
> 51-50-51-49-50-52-51-50 etc. And I just wane to have the number 50
> as output, so the numbers 51-52-49 are just forgotten. And when the
> number is close by 55 the output have to shown 55 en not
> 53-55-54-53-55 etc. Clear?
> Is there a solution for my problem. Could somebody give me a hint/
> starter of something. I don’t know how to begin.
>
> Thank You
>
> Nicolette
>
On Jul 28, 2008, at 5:54 AM, Nicolette wrote:
> The output data of the axes of the Wiimote are, how shut I put it,
> very nervous and not stable.
There are many ways to smooth a number stream. This is a sort of heavy
handed method:
Chris Muir
cbm@well.com
http://www.xfade.com
I don't remember whether I've put this patch up before.
A number of beginner workshop students have found it
useful. It lets you set the amount of smoothing you
want.
gregory
On 28 juil. 08, at 14:54, Nicolette wrote:
> Hello,
>
> I'm just a newbie with Max/msp, and trying to figure out something.
> I'm working with the wiiRemote in max/msp by using the tk.wii.
> The output data of the axes of the Wiimote are, how shut I put it,
> very nervous and not stable. The data is not steady even when I'm
> holding the Wiimote still (just lying it on the table). What I want
> is to get steady numbers.
> For example. the output is just jumping from 51-50-51-49-50-52-51-50
> etc. And I just wane to have the number 50 as output, so the numbers
> 51-52-49 are just forgotten. And when the number is close by 55 the
> output have to shown 55 en not 53-55-54-53-55 etc. Clear?
> Is there a solution for my problem. Could somebody give me a hint/
> starter of something. I don’t know how to begin.
In Max 5 you can use [zl stream] + [zl median] for instance:
ej
Lovely patch Emmanuel !
If only I had this one year ago when I started my wii project...
Quote: Emmanuel Jourdan wrote on Mon, 28 July 2008 23:36
----------------------------------------------------
>
> In Max 5 you can use [zl stream] + [zl median] for instance:
>
>
>
> ej
>
>
>
----------------------------------------------------
the [slide] object may help.
On Mon, Jul 28, 2008 at 8:54 AM, Nicolette wrote:
>
> Hello,
>
> I'm just a newbie with Max/msp, and trying to figure out something.
> I'm working with the wiiRemote in max/msp by using the tk.wii.
> The output data of the axes of the Wiimote are, how shut I put it, very nervous and not stable. The data is not steady even when I'm holding the Wiimote still (just lying it on the table). What I want is to get steady numbers.
> For example. the output is just jumping from 51-50-51-49-50-52-51-50 etc. And I just wane to have the number 50 as output, so the numbers 51-52-49 are just forgotten. And when the number is close by 55 the output have to shown 55 en not 53-55-54-53-55 etc. Clear?
> Is there a solution for my problem. Could somebody give me a hint/starter of something. I don't know how to begin.
>
> Thank You
>
> Nicolette
>
>
--
Morgan Sutherland
I thought that it might be interesting to gather the various solutions
to this data reduction problem together in one patcher so that they
can all be run on the same data. It's clear that they all have their
plusses and minuses, depending on what your goals are:
Very good Chris !
this will go to my max extra menu right now.
This should part of the Max bundle IMO.
Quote: Chris Muir wrote on Tue, 29 July 2008 03:31
----------------------------------------------------
>
> I thought that it might be interesting to gather the various solutions
> to this data reduction problem together in one patcher so that they
> can all be run on the same data. It's clear that they all have their
> plusses and minuses, depending on what your goals are:
>
----------------------------------------------------
Thanks for all your reaction. I'm only working in Max/msp 4.5 for Windows and I don't know how to read the patchers of Max 5 :S
Nicolette
Chris' patch with the simple solution, [slide] added:
On Mon, Jul 28, 2008 at 9:31 PM, Chris Muir wrote:
>
> I thought that it might be interesting to gather the various solutions to
> this data reduction problem together in one patcher so that they can all be
> run on the same data. It's clear that they all have their plusses and
> minuses, depending on what your goals are:
>
> [code deleted]
>
>
--
Morgan Sutherland
And, as always, lp.stacey is your friend for averaging.
There is an example patch called "Smoothing Sensor Data" included with the Litter Power Extras/X-Amples/. I can include it here, but you'll still need to grab the Litter Starter Pack to use it. URI in the .sig.
In Max 4 format, because that's the machine I'm on right now:
Very simple solution to this question is to use "split" objects to achieve this. What a split object does is basically take an incoming number in its inlet, and says "if this number is in between two numbers specified, output the number out the left outlet, and if its NOT in the range, output the number out the right outlet." What you can do, is, in the object, specify you're number range you want to translate to one number (say in your case, 49 as lower limit, and 51 as upper limit). Then, out the outlet that says "send number if within limits," attach this to a message box that say "50" in it. What this will do, is it will take the numbers "49" "50" and "51" and spit them out as "50". You can make as many of these as you want. Just make sure to only use the "if within limits" outlet, or else all your "splits" will be firing off if the number is not within their limits and screwing stuff up.
Here's some simple code that illustrates what Im talking about:
{
"boxes" : [ {
"box" : {
"maxclass" : "message",
"text" : "10",
"fontsize" : 12.0,
"outlettype" : [ "" ],
"numinlets" : 2,
"numoutlets" : 1,
"patching_rect" : [ 677.0, 628.0, 32.5, 18.0 ],
"id" : "obj-73",
"fontname" : "Arial"
}
}
, {
"box" : {
"maxclass" : "button",
"outlettype" : [ "bang" ],
"numinlets" : 1,
"numoutlets" : 1,
"patching_rect" : [ 723.0, 668.0, 20.0, 20.0 ],
"id" : "obj-69"
}
}
, {
"box" : {
"maxclass" : "number",
"fontsize" : 12.0,
"outlettype" : [ "int", "bang" ],
"numinlets" : 1,
"numoutlets" : 2,
"patching_rect" : [ 687.0, 566.0, 50.0, 20.0 ],
"id" : "obj-64",
"fontname" : "Arial",
"parameter_enable" : 0
}
}
, {
"box" : {
"maxclass" : "newobj",
"text" : "split 10 15",
"fontsize" : 12.0,
"outlettype" : [ "int", "int" ],
"numinlets" : 3,
"numoutlets" : 2,
"patching_rect" : [ 677.0, 592.0, 65.0, 20.0 ],
"id" : "obj-62",
"fontname" : "Arial"
}
}
],
"lines" : [ {
"patchline" : {
"source" : [ "obj-62", 0 ],
"destination" : [ "obj-73", 0 ],
"hidden" : 0,
"disabled" : 0
}
}
, {
"patchline" : {
"source" : [ "obj-73", 0 ],
"destination" : [ "obj-69", 0 ],
"hidden" : 0,
"disabled" : 0
}
}
, {
"patchline" : {
"source" : [ "obj-64", 0 ],
"destination" : [ "obj-62", 0 ],
"hidden" : 0,
"disabled" : 0
}
}
],
"appversion" : {
"major" : 6,
"minor" : 1,
"revision" : 7,
"architecture" : "x86"
}
}
I was trying to use [slide] for portamento but when the slide time is high and the incoming notes are fast, the output gets kind of bogged down in a broad average of the incoming values.
I tried using line instead because it seems better at changing direction, but has a distinct stepped or zippering quality I can't get rid of. I thought this was solved in the past by giving it an initial grain interval, but it doesn't seem to work now.
I might have mis-remembered using [line] instead of [line~]
I think slide and line act in the same way, depending on the "grain size"...
Here's an example with a bline, to illustrate. With the same values, the lines are similar...
lots of data in realtime and high priority recommends signal rate.
Sorry I don't think I made myself clear.
There were two points, but I'll focus on one first to help clarify.
Is there a way to solve the zippering problem I'm finding with line, vs line~?
The included patcher was incomplete, we cannot copy/paste.
Sorry about that - fixed.
Yes. Use line~ instead of line.
Or if you want steps but un-zipped, use both line and line~:
You didn't define an initial grain interval in the copied example ( [line 10.]).
The default grain interval is 20 ms, resulting in that visible stepped aspect. If you lower the grain interval you'll get rid of that problem. Try [line 10. 2.] and see the difference.
Oh Pedro - thank you!
I had tried different numbers, but had this idea that 10 was actually pretty low.
I had been going higher - maybe getting myself confused with slide where higher values = 'smoother'.
Your "10" value was not the grain interval. It was the initial value. The grain interval is the second argument, which you didn't specify, thus it was set to 20 ms, the default.