spacebar not work in host. have mux case WM_KEYUP code you write in manual ?

Official support for: mutools.com
Post Reply New Topic
RELATED
PRODUCTS

Post

Hi Jo
in your manual stand this
Generally operating systems send key presses to the focused control in the focused window. When that control does not handle that key press it should forward it to the next keyboard handler, eg. its parent control. If all controls properly follow this rule, all will work fine as the user can indicate which control must have keyboard focus.

But when using VST plug-ins it occurs that the VST plug-in editor does not properly forward unhandled keyboard events and this may result in, for example, that while the keyboard focus is on the plug-in editor, pressing the spacebar does not start/stop the main Play function. And besides that, there also is a non-comformity in Microsoft Windows: When a child window (the very VST editor) does report that a key press is unused and hence it gives the key message to DefWindowProc, Windows does not forward it to the parent window. That's a serious shortcoming in the Windows system. MuLab cannot do much about these cases except for this workaround: When you click the top control bar of a VST editor (thus in the MuTools GUI area) this will shift the GUI focus to the window's top level and hence key presses will be processed by MuLab. So that way you can quickly force a GUI focus shift to the MuLab GUI and hence eg pressing the spacebar will start/stop playing the composition.

Request to Windows VST plug-in developers:
To workaround that shortcoming in Windows OS, please do this in your VST editor's window message function (pseudo code):

case WM_KEYDOWN:
case WM_KEYUP:
if (ProcessKey(Msg,wParam,lParam)) { // ProcessKey() forwards it to the relevant control in your UI and when they key is handled = consumed, it returns true
return(0);
}
else {
host_hwnd=(HWND)AEffEditor->systemWindow;
return(CallWindowProc((WNDPROC)GetWindowLongPtr(host_hwnd,GWLP_WNDPROC),host_hwnd,Msg,wParam,lParam));
}

Using the above code (ie. the 'else' section) not only the unprocessed key messages in the main VST editor window are properly forwarded to the host window, even unprocessed key messages of separate plugin windows (if any) are forwarded to the host window. That's a double advantage.
If MUX have such code wy it fail in rapidcomposer ?. do the DAW developer too need add some code that space handling work good ?
win 10 64 22H2 intel i5 8600K (6*3.6 GHZ) 32 GB Ram

Post

MUX VST does forward unprocessed events. Of course the host (Rapid Composer in this case) has to process them too, but i have no control over that. Maybe check with the Rapid Composer devs?

Post

In Rapid composer messages send from plugin are process now in beta 9. i see problem in cubase too with sample tank 3. work on RC and cubase same. mulab work ok. when press delete key or backspace key sample tank 3 forward this to DAW and DAW delete a phrase. MUX work ok in cubase. MUX in RC do same as sample tank 3 and delete a phrase in RC when MUX not do action for delete or backspace.

i think easiest and best solution is, when the DAW only process space , shift space, alt space, control space from plugin send, or the plugin only send space to DAW. or do you know other keys that the daw need process that send from Plugin ?
win 10 64 22H2 intel i5 8600K (6*3.6 GHZ) 32 GB Ram

Post

I write in melda forum(melda habe lots good plugins), because when there preset browser window is open, no space work. he write (shorten)
http://www.kvraudio.com/forum/viewtopic ... 8#p6797658
Well, what he writes is a brutally simplified thinking...The host needs to do that in the global message loop if it wishes to receive these messages.
maybe you can explain precise wy it not work. this method also from microsoft is suggest can not work ?.

https://stackoverflow.com/questions/667 ... ent-window
win 10 64 22H2 intel i5 8600K (6*3.6 GHZ) 32 GB Ram

Post

I disagree with what Melda wrote. The solution i propose is a neat structured solution. Using a global message hook is a dirty hacky solution. That's my humble opinion. But i'm open for direct discussion with other devs.

Post Reply

Return to “MUTOOLS”