increasing a value proportionally to a float in a certain range only
So I'm banging my head against the wall. I'm a little bit of a noob in MaxMSP and I'm trying to make a patch that can translate the information received from a sensor (between -1. and 1.).
The variation speed should be proportional to the amount of "force" received in the sensor... That is to say, the closer the sensor value to "1.", the faster should the number increase, and viceversa for "-1." (it should decrease faster).
Another restriction is that the number that increases needs to stay between 4. and -4. and when those values are reached, even though the sensor keeps telling it to increase, it should stay in that value. This relates to another problem, the number should be responsive to an immediate change of sign in the sensor input. I have tried using a [scale] [metro] [f] [accum] [line] and [zmap] combination and it works more or less ok, the only problem is that in the [accum] object, the values keep increasing if the sensor keeps sending a positive or negative value... therefore to start decreasing from 4 down to -4 again when the sensor starts sending negative values again it takes a long time, since [accum] can be sending out values by 8. or 9.
I tried clipping the value output of [accum] and sending it back to itself, but I overflown the program... Tried delaying the clipped value with [delay] and [f] but I also crashed the program :(...
Any ideas would be very much appreciated! :)
Hi,
do you mean something like this?
THT,
Ádám
I sorry i cant check it at the moment , and i dont really follow the flow because i cant compile so fast in my head :D ... but wht came to my mind ,if you want your value growth in exponential fashion ,you need to multiply them by itself . But the values cant go over "1" ,this range you can scale up later on . So as said ,you need to multiply it by itself ,you can even use several multiplications . This way you will get exponential curve of values . im sorry if im missing the point
Hi,
I was assuming that you have a continuous data input form the sensors. After checking your original patch, I realized that this might not be your case, so here's an updated version of my suggestion:
Hope this helps,
Ádám
P.S. I encourage you to post patches to the forum as suggested in the forum guidelines. This has many benefits, one of them being that people who read the forums as RSS feeds (like me) instead of using a web browser, will also see your posted patch. I didn't even see that you submitted a patch until I came to this page...
First of all I want to apologize for not posting in code mode... I didn't know how to do it, but I will check that later on.
Second, thank you Ádám... your solution is more elegant than mine... which was extremely complicated for such a simple task. However it was good to explore all those objects that I explored :)
The data is not continuous... is sent through UDP in OSC format at a variable update rate. Actually when the sensor stops receiving input, it doesn't automatically go back to zero. To make it go back to zero (so the final value stops changing) after a certain amount of time (let's say 400ms) without input. I thought something like [counter] and [change] to measure time elapsed since last change, and in case it reaches a certain value send a 0. value to the input. What do you think?
Another question: Why use qmetro instead of normal metro?
Thank you very very much again :)
Hi,
you should check the [delay] object. You can build a very simple inactivity detector with it, like in the patch below:
Regarding [qmetro], just read the help file, and you'll see. In most cases, I prefer [qmetro] over the original [metro] object when the metronome interval is small, since when the CPU gets overloaded and the system would slow down, [qmetro] will automatically drop those bangs that can't be processed real-time.
Hope this helps,
Ádám