Strange listfunnel management of Nodes' output
As shown in the attached, I generate a list of 0./1. out of a Nodes object. The list is then indexed by a listfunnel object.
For some reasons, when 1. is generated out of some of the nodes, node 7, for instance, as exemplified, even if the incoming list contains 7 1., the output is 7 0 instead of 7 1. . For different nodes, like node 1 or 8, the process works as expected.
When feeding the listfunnel object with the exact same list as generated by the Nodes object, but "manually" everything works well.
I've spent hours trying to understand why, with 0 success. What happens ? If someone could provide any clue, this would be highly appreciated !
All the best,
Sébastien
listfunnel -> unpack -> == 1. -> pack is not a good way.
because in max float does not have to be
exactly what it looks like in GUI objects.
In addition, you are generating too many an too fast repeated lists from nodes.
insert zl.change at node output and input,
then to detect which 1 of 16 nodes has mouse over it
use != 0. instead of == 1.
Hi Sebastien found: a round after the nodes output : 7 outputs 0.950799....
hth
Thank you very much, both of you, for the fast responses !
I fully understand the need of zl.change, now.
However, the "rounding" issue is still unclear to me:
I see no logical reason to explain the fact that the 7th node outputs a differently rounded number (all the other nodes are exactly the same, at least to my understanding),
In the patch I sent initially the output list did show the 1. value when mouse was over the 7th node. Why, in MIZU's example, does the exact same Node object would output a different list of values, in the same conditions, and before any further processing. See attached.
Is it something that one could expect or do I miss something ?
But thanks again for helping me improving my patching skills so kindly !
Sébastien
it is not only float as such, but also timing.
You were sending massive amount of messages
which passed through the list.
And manual manipulation of GUI elements in max is also adding to the problem.
the reason your nodes should output 1.
is setting the coordinates using this :
but one can move you nodes out of perfect position,
which would offset their value.
take a look at different, simplified detector using zl.sort
and also != 0. instead of == 1. if you want to keep listfunnel
I would bang the initialising message for nodes position
after mouse release, to realign them in case they got repositioned.
Could it be : its no pixel in the center of node 7 who gives 1. ? So mouseidle can't go to 1.
and the tragedy of float : == 0. only true when the 64th bit is 0
bzzz
edited added:
in the pdf: i changed the knobsise and maybe the dimension of the nodes object
& strangely, on my screen, in the 7th node, the red knob is never exactly at the center
maybe ?
michel
Well, now I am confused, but the other way round ... ;-)
1. I understand the == /float issue, and that there may be a difference between the float shown in the list and the actual number kept by the computer. Adding the round object just outside Nodes seems to be sufficient to solve the entire issue ?
2. But as far as zl.change is concerned, thinking twice, I may finally miss the point. If I move the curser inside the Nodes object, as it does not move continuously, but only step by step, the list is output without clicking at every move and changes every time anyway. So each output list is different from the previous one. The zl.change step does not add value, if I understand well the purpose of it.
I don't want to be tiresome, just trying to understand and learn from my mistakes .... you have been very patient and reactive so far, thanks again for that, guys.
@ SOURCE AUDIO: thanks for the $1-filtering-out-of-zl.sort trick !
Sébastien
on very mouse change in node, you genearte a list at rightmost outlet
and round it, then resend back to node to snap to 16 node centers.
Without any restrictions.
insert print object directly to node output in your ORIGINAL patch,
and watch what gets out....
You never mentioned if you use that nodes ONLY when mouse
is NOT clicked.
In case you also need clicked output, you will have ever changing float 0. - 1. list output, which if run through round object,
as inserted in MIZU's patch will output whole list on slightest input change.
Hello SOURCE AUDIO,
"You never mentioned if you use that nodes ONLY when mouse is NOT clicked".
That's absolutely correct. My apologies. This was probably too obvious for me, as I initially chose Nodes for this very reason ...
And yes, using "print", I can see that Nodes constantly outputs lists even though no change is made. I previously, wrongly, used a simple "button" object to track when Nodes outputs something, and the button blinked only when changes where made. I couldn't see the continuous flow of data with this method (to my credit: that's a bit confusing ....).
I don't want you both to lose more time on this. Thanks to your patience and dedication : I now much better realize the essence of my initial issue, and have a much clearer understanding of what happens "behind the scene" in MAX when I use the Nodes object.
I am sincerely grateful for that.
Have a great day ahead, folks.
Sébastien
don't worry, if it was loss of time, no one would reply to questions
in the forum.
I see only one problem - one can move nodes from original position.
You can solve that by repositioning the nodes, using that message,
when mouse button is released.
middle outlet reports node state if it changes, set it filtered in inspector
then whenever one node changes .... you get the idea
Hi,
A quick update to let you know that my patch was further elaborated as explained here: https://cycling74.com/forums/n4m-facemesh-handpose-google-mediapipe#reply-6499c2478b3d250014acdcbc.
Cheers,
Sébastien