Comparing thee values to see which is maximum
Hey hey, I would like to compare three values, all coming from real time data, to see which one has changed most since the last update (maximum). I first used if statements now I am using the expr object, but I am still facing the same issue.
I already figured that it must be coming from the values being not triggered at the same time, wherefore not all values can be compared. I tried to cheat a bit by using a delayed bang to output the data together, but also that doesn't work. Strangely if I try to do it by hand it works.
I've checked the forum and already learned this is something many people struggled with but I couldn't find an answer that helped me understand and learn how to go around this (some things are still a bit hard for me to understand sorry :/).
Does someone have a hint maybe? Let me know and thank youuuu!
This is what I would do:
Your whole [p plus] can be replaced by a simple [abs 0.] which just outputs the absolute value of a float (multiplies the input by -1. if it is <0.)
Then, I use array sorting to check from which sensor we get the biggest change.
delta is good, abs() is good.
now to the third part, which can also be simplified: note that [maximum] will take lists.
this can be simplified , and needs no
arrays , I mean can work in older max versions.
list to compare can be any size ...
zl.sort was my first guess but for some reason I got confused by its "alphanumerical" ordering and thought it would not properly sort just numbers including floats. But turns out it does!
Thank you both for your input :). To begin, TFL getting the difference and negative value works perfectly. But I found out that the value doesn't stay constantly, but is immidiately set to 0. after outputting the difference. Anyways I tried to continue using both options, using the arrays and the list to compare. Unfortunately the same happens, the result is outputted but resets immidiately. I feel the array does give me the number with the highest value, or I am reading the zl.sort output wrong, but again it disappears so quickly I cannot be certain. Do you know why this happens?
You are applying two times the same calculation. Here, my [t f f] > [- 0.] > [abs 0.] is equivalent to Source Audio's [t l l] > [vexpr abs($f1 - $f2)], except that my method for single values that then need to be packed as a list, while Source Audio first make a list and then do the math.
Then for the sorting, both the array and zl.sort methods should give the same result. What happens in your patch is that there is a [pak f f f] before the zl.sort. That pak will output a list each time it receives anything from any inlet, which we don't want.
You don't need more than that:
About the speed of the output, replacing the [pak] by a [pack] or [join] as I did should help (as you'll get one output for each new batch of received values, instead of 3), but at the end it really depends on the nature of your incoming data (which refresh rate?) and what you actually want to do with this processing. Maybe you need a bit of data smoothing at some point.
Ahhh omg of course! Thank you TFL :)
And yeah the refresh rate is quite slow, so every 30 seconds. But I don't know yet how they data will look like exactly, this is just a simulation to set up the code. But as soon as I know how it looks like I will see if I need to smooth it out.
Anyway, thank you two!!!!
if your input does not receive all values at same time, you must use pak or join with all
inputs trigger enabled.
otherwise only 1st member would output the list.
in this specific case - where you parse 3 values from that data url,
input is known, and can be simplified like this :
if you only want the value (without index) , maximum is enough