mousestate polling too much

Jan 23, 2011 at 9:14pm

mousestate polling too much

my question there : isn’t it possible to have a mousestate object to behave as it will only poll events if the windowin which it is embedded is the frontmost window ?? so that your mouse doesn’t accidentally interact with a window invisible under many layers… i would think something that obvious would be some kind of “mode 4″ of the object, but i found nothing in the reference. did i miss something ?

Jan 23, 2011 at 9:34pm

My first thought was to get the state of your patcher window with thispatcher or pcontrol and use that to turn mousestate polling on and off. A quick look at the thispatcher and pcontrol didn’t turn up an obvious way to determine if the window is frontmost or not. Maybe scripting could help?

Jan 23, 2011 at 10:05pm

Check out the active object.


Jan 24, 2011 at 10:25am

Hi Ben,
i checked it and at first glance i thought it was it, but then i realized that it won’t work inside a patcher which is inside a bpatcher. It behaves strangely maybe, i thought “active” inside a bpacher would behave as if it was a part of the parent patcher, but apparently not, and it seems that a patch inside a bpatcher will never report as active ?.. maybe there are other workaround just with the bpatcher object, like a “dont click through” attribute ?
and Holland i checked thispatcher scripting, it won’t be enough, mb js will go further but i don’t know a thing about it…

Jan 24, 2011 at 3:59pm

It is working here as expected, but maybe I am missing something about your setup. Maybe post a very simple example that is set up with the patcher hierarchy that you are using.

– Pasted Max Patch, click to expand. –
Jan 24, 2011 at 7:49pm

hm… it’s not exactly what i intended to explain, so here is what i’m trying to do :

– Pasted Max Patch, click to expand. –

thanks for caring anyway !

Jan 24, 2011 at 7:58pm

Ah, yeah, that won’t work. One way to do it is with the hover object and a named bpatcher:

– Pasted Max Patch, click to expand. –
Jan 24, 2011 at 8:37pm

i didn’t know this hover object
it’s my problem nearly solved – i can use this solution but ideally, the whole thing should be inside the bpatcher. I’m beginning to wonder if it’s doable at all, but it would be cool cause i often use that abstraction i want inside a bpatcher, so if i don’t have additive programming to do each time it’s all the best…
Anyway i can live with that solution :) or i can replace the “hover route mybpatcher etc…” by just an “active”, wich is enough because i just need the mousestate not to be polling when the parent windows is not the active one.
Again thanks for the help ! wall after wall i progress… ;)

Jan 24, 2011 at 10:02pm

Why not just put the active object in the top level patcher, and have an inlet to control polling on the bpatcher?

Jan 25, 2011 at 11:10am

hi Chris,
that’s what i choosed at the moment, but having it inside the bpatcher would have been really nice.


You must be logged in to reply to this topic.