Mac Mouse problems driving me mad

So, my plugin runs fine on Windows. Never had a problem. But on the Mac there are strange problems, that will eventually make me lose my head.

Following problems occur:

In AU Lab, I open the plugin, and there are knobs in it that will change the colour when the mouse enters them. On Mouse Exit they become normal again. The thing is, that in AU Lab, half of the time, when the mouse enters them, nothing happens. Then after some time, sometimes they react on mouse entering, sometimes not. Sometimes they also just flash up once when the mouse enters, and then get normal again while the mouse is still over them.

Other people have told me, that in Logic (which I do not own), the repainting of the knobs stopped, so when the user moved the knobs, the result was hearable in the plugin, but the knob did not update its graphics.

Edit: Same Problem with the JUCE Demo AU! Sometimes the keyboard and slider reacts to mouse enters and exits, and sometimes not.

What could this be?

Getting it working at all almost drove me completely mad! On the mac, the hosts seem to eat mouse-move events, so I had to come up with all kinds of hackery to work around this. I think I eventually used a timer to just check the mouse position occasionally and fake the mouse enter/exit events, because there was no way of reliably getting the real ones.

But still, it doesn’t seem to work properly. Neither my plugin, nor the Juce Demo AU work.

I remember that I had to do the same thing as you described with Borland C++ on the PC (generate Mouse enter/exit events via a Timer). Hmm no, I just intercepted the WM_MOUSEMOVE and looked if the last component under the mouse was the actual one, and if not generated the messages… But that’s another story…

So my next 2 questions are:

  1. What can I do to make it work?
  2. Why did, in my friends Logic 8, the repainting of the knobs not happen anymore (the mouse events got captured, since one could hear the results, but the graphics would not be updated) ?

I really have to fix these issues, as I already paid for my Juce license :slight_smile: And I want to release the AU version as fast as possible (the Windows VST version is out already).

Well I don’t know about the repaint problem - that’s a new one on me. Have you got a way of replicating these things reliably?

The people where it happened told me that it just happened during a session with Logic 8 and then the controls didn’t react, even if one closed Logic and openend it again I think (which is completely misunderstandable for me, since this would require Logic to save some “internal” state of the plugin). One could still save the preset, then close the plugin (really close it, not only the editor), open it again, and then load the preset again - then it works normally for a while again. It’s realllly weird.

Perhaps this is a bug in my plugin ? I don’t know. But I simply cannot imagine the cause of it.

I noticed in juce_AudioUnitWrapper.cpp that the Timer that handles the Mouse Events is started by a MouseMove itself (line 796). Why isn’t it started directly? (i.e.: since mouse events are not sent to the plugin, how can the timer then be started by a mouse event ?)

Why are the mouseEnter()/mouseExit() calls not properly generated? Even with a Timer-based solution, this should work.

I just checked, in Ableton 7 Demo & Logic Express 7, the highlighting via mouseEnter()/ mouseExit() works. But in AU Lab it does not work really. Perhaps it has got to do something with the fact that the host is Carbon or Cocoa?

Edit: Also installed Logic 8 on my IBook G4 800 MHz (puuuh) and after a while, the knobs don’t highlight anymore when the mouse hovers over them, although they still turn when one presses the mouse and moves (well, I did not test hours like my beta testers did)…

Jules, here’s something I found, don’t know if it helps:

http://lists.apple.com/archives/carbon-dev/2006/Nov/msg00331.html
http://lists.apple.com/archives/carbon-dev/2006/Nov/msg00300.html

Yeah, that doesn’t really help, as I already catch the mouse-move events. Not sure what’s going wrong, I’ll need to do some digging.

Well, then here’s something that might help: I just downloaded MuCoder’s Hypercyclic, which is a JUCE AU plugin and tried it in AU Lab.
Hypercyclic’s button components also highlight/unhighlight on mouseEnter() and mouseExit(). What I noticed is, that the highlighting still occurs, but not when the mouse is over them but when it goes over the screen somewhere else. I am nearly sure, that the origin of the plugin is not taken in account. So when the plugin is at x=100, y=100 and the mouse is at x=10 y=10 on the Desktop, the component that is in the plugin at x=10 y=10 (desktop: x=110, y=110) is highlighted.

What’s strange is that this doesn’t happen all the time. Is it possible, that somehow, mouse messages are sent twice to the components? One time, relative to the plugin’s window, and one time not relative to the plugin’s window? If I comment out the 2 startTimer()'s in juce_AudioUnitWrapper.cpp, it makes absolutely no difference to the highlighting.

Hi Zamrate, Jules, I just found your post

I tested hypercyclic with aulab on OSX 10.4.11 with aulab and the mouse movements seem to be correct (although keyboard input doesn’t work).

same thing in Logic Express 7.2.3 (where keyboard does work). The only little glitch in Logic is that the highlighting of some buttons seems to stutter a bit when you move the mouse over them. This is only for a few small buttons, the larger ones and knobs seem to work just fine

so what versions are you on?

one thing I learned in the past: if mouse behaviour is jerky while dragging a knob on Mac it could be that you somehow have an update to that control that is triggered from a mousehandler, causing some interference with the updates that the drag itself does already. The solution then is to refrain from updating the button until the dragging has stopped. Could it be that the highlighting logic sort of causes a similar interference (but with a race condition, so it doesn’t happen always) ?

one other thing I observed: The default Juce message listener infrastructure seems to drop events from time to time, i.e. they are not (or not always) queued? Could be that is just an optimization to combine multiple identical events into one though. Maybe Jules can comment on the architecture… Anyhow, for hypercyclic I know I had to add my own message sources/listeners there where I wanted to be absolute sure no events were dropped.

I think, Logic 7 is still a Carbon app whereas Logic 8 is a Cocoa app, and I think that AU Lab is Cocoa, too. I think the problem only arises with Cocoa hosts.

I have a IBook G4 - slow machine - so perhaps this amplifies the problem,… I don’t know, … What’s for sure is that the same problem also arises on other people’s dual G5 machines. If I just run the Juce Demo AU and go over the Juce Demo AU keyboard, sometimes its keys will highlight and stay highlighted, sometimes they don’t react at all and sometimes they react when the mouse is somewhere completely different on the screen. Same behaviour for Hypercyclic and my own plugin.

I use JUCE 1.45 with OS X 10.4.10

I just pray that someone will find a solution for this problem, because I am no Mac expert. The only thing I know is that I cannot sell my AU plugin as long as this bug stays in there…

hmm, could it be a PPC thing? I’ve only tested on an intel mac mini so far.
I’ll try to get some tests done on a PPC machine…

Good idea! I don’t have an Intel Mac, so this would be a nice test.

Hi all,

I am experiencing some mouse problems too but strangely, it looks to work fine for me in AULAB (intel /10.5.2).

I have recently built my plugin as standalone. everything works fine on windows but on mac the whole messaging system seems to be slowed down.
The mouse events are received strangely and if i move the mouse fast, it can skip the mouse exit functions.
I notice problems mainly happen when i am dragging on a component.

I know it’s not exactly the same symptoms as you guys but can it from the same problem source?

cheers

I also suspect a flaw in the message flow.
Are you sure that this is not the problem I had to before getting rid of the 2 startTimer()'s in the AUWrapper C++ file: Before removing the 2 lines, the plugin’s buttons would respond if the mouse was somewhere else on the screen! For trying it out, I suggest putting the plugin window near but not on the upper left corner, let’s say at X=0 Y=100 and the moving the mouse in the region over the plugin. Check if the buttons will not highlight (triggered by mouseEnter()).

What host do you use for the plugin?

after investigating a bit, it seems that the mouse works fine but there’s a mess with the messaging system.
it looks like the juce message thread and the UI thread have the same id…

that would explain why everything looks ok for components who are fast to draw but the messages are delivered late when the component are longer too redraw.

But the UI thread is always the messaging thread…

oh true…

i found out that the all stuff is slow only when i’m dragging on a component. while i’m moving the mouse everything is slow but jump to normal position as soon as i release the mouse button…

this really happens only on the standlalone app, the plugins are ok.

any idea where to look guys?

I’m in an “out of ideas” state on this one. Does anyone actually know a non JUCE-based plugin on Mac that performs highlighting of the controls when the mouse just hovers over them? I found none yet.

no, I’ve never seen one either. And having tried to implement it, I’m not surprised!