Yuni

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.

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. 

smoothing-out-numbers

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

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, 

-otherwise Tristan's library has a ready-made filter called 

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 

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 

On 28 juil. 08, at 14:54, Nicolette wrote:

> 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 

> 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 

> Is there a solution for my problem. Could somebody give me a hint/ 

> starter of something. I don’t know how to begin.

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.

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

There are many ways to smooth a number stream. This is a sort of heavy 

> 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

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.

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

In Max 5 you can use [zl stream] + [zl median] for instance:

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

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:

Quote: Emmanuel Jourdan wrote on Mon, 28 July 2008 23:36
----------------------------------------------------

>
> In Max 5 you can use [zl stream] + [zl median] for instance:
>
>
>
> ej
>
>
>
----------------------------------------------------


On Mon, Jul 28, 2008 at 8:54 AM, Nicolette wrote:

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

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

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:

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:

this will go to my max extra menu right now.

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:

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

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:

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

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:

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

                "maxclass" : "button",

                "outlettype" : [ "bang" ],

                "numinlets" : 1,

                "patching_rect" : [ 723.0, 668.0, 20.0, 20.0 ],

                "id" : "obj-69"

                "maxclass" : "number",

                "outlettype" : [ "int", "bang" ],

                "numoutlets" : 2,

                "patching_rect" : [ 687.0, 566.0, 50.0, 20.0 ],

                "id" : "obj-64",

                "fontname" : "Arial",

                "parameter_enable" : 0

                "maxclass" : "newobj",

                "text" : "split 10 15",

                "outlettype" : [ "int", "int" ],

                "numinlets" : 3,

                "patching_rect" : [ 677.0, 592.0, 65.0, 20.0 ],

                "id" : "obj-62",

            "patchline" :             {

                "source" : [ "obj-62", 0 ],

                "destination" : [ "obj-73", 0 ],

                "hidden" : 0,

                "disabled" : 0

                "source" : [ "obj-73", 0 ],

                "destination" : [ "obj-69", 0 ],

                "source" : [ "obj-64", 0 ],

                "destination" : [ "obj-62", 0 ],

{
	"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...

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.

lots of data in realtime  and high priority recommends signal rate.

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.

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.

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.


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

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.

Smoothing out numbers