Juce 754 Mac OS 10.5.7 Live 8.0.3 vst carbon version of plugin
I have overridden the virtual mouseEnter / Exit methods to do control highlighting and display dynamic information on each control, but these methods don’t get called. This worked on the old 1.46 code, but is now broken for the vst carbon version.
Anyone have any ideas? This and random crashes on exit, and a few other bits and pieces make the current tip unusable for production code.
Andrew Simper
Have the method signatures changed at all? You may need to update yours.
No, and I put breakpoints in the base class as well, nothing is being called.
Andrew Simper
In live 7 it’s all working as expected… I don’t have live8, but will grab a demo and try that asap.
More worried about the random crashes you mention - got a stacktrace?
Hi.
I have problems with mouseMove on some hosts with latest juce.
Some customers reports problems under Mac and GB9.
Mouse moved over controls, but nothing changes(handler method not called). Other host works correctly.
VST, RTAS - also. Mouse drags works correctly.
Something strange…
Bear in mind that on the mac, mouse-enters and mouse-moves are never used unless a window has the focus. Does it work properly if you click on the plugin window? If so, that’s not a bug, it’s just the normal mac UI behaviour.
Thanks.
It is bad… Some host(like Logic) never sends mouseMove to plugin window(only if mouse button preset).
Also, one moment.
Latest juce, plugins, Mac, VST, AU(possible RTAS), all hosts.
AlertWindow::showMessageBox place messagebox under plugin window. So i need to add setAlwaysOnTop in juce code.
Is it possible to add it to juce(as param, or directly in code)?
Thanks,
Yes, I suppose the boxes could be always-on-top in plugins.
Thanks, glad to hear.
Also, i have some strange issue with RTAS(win + mac).
There is code line in wrapper:
case 0: return AudioPluginFormatGeneric // (something like this).
To make plugin works and recognized in need to chage it to “return AudioPluginFormatStereo”
All known(by me) developers need to do it too.
Maybe some bug in juce, or in our code?
Michail.
I can’t find the line you’re talking about - can you give me a filename to look in?
Do you mean ePlugIn_StemFormat_Generic? If so, then if your plugin’s got 2 channels, then it does return ePlugIn_StemFormat_Stereo. It only returns ePlugIn_StemFormat_Generic if you’ve got 0 channels… Can you explain a bit better what’s actually going wrong?
My plugin is synth, it uses {0, 1}, {0, 2} channels configuration.
If ePlugIn_StemFormat_Generic is used - (for input channels it will returned) - plugin will not recognized.
Looks like synch must use input channels == output channels.
Michail.
Ok… How about doing this:
type->DefineStemFormats (getFormatForChans (channelConfigs [i][0] != 0 ? channelConfigs [i][0] : channelConfigs [i][1]),
getFormatForChans (channelConfigs [i][1] != 0 ? channelConfigs [i][1] : channelConfigs [i][0]));…so that if either the input or output has 0 channels, it’ll use the format of the other number for both input and output? Seems like a nasty hack though…
Works for me! Thanks.
I tracked the lack of mouseEnter / mouseExit messages in the latest cocoa based guis. I had #define JucePlugin_EditorRequiresKeyboardFocus set to 0, which sets the flag ComponentPeer::windowIgnoresKeyPresses for the main editor component when it’s added to the desktop, which is checked by bool NSViewComponentPeer::canBecomeKeyWindow() to let the OS know if the window can become the “key” window. Now on mac the “key” window is not just if a window wants and can handle “keyboard” events, it’s also used for mouse events. So if you want to track the mouse you need to #define JucePlugin_EditorRequiresKeyboardFocus 1 and make sure setWantsKeyboardFocus (false); is called on every control you use and return saying any keyboard events you get are not handled so they will be passed back to the host.
