VST3 and event loop

[iurie]

Hi! Does anyone know how or where can I implement the event loop when developing for VST3, say, if I am using WinAPI to build the GUI? For example LV2 format provides an interface idle() that is called by the host about 30 times per second and in which you can put, say, your function to process events. I understand that in "tresult PLUGIN_API ClassName::attached(void* parent, FIDString type)" you can create the GUI window, but I can't find where I can process events (I am referring to Win API events). Does the VST3 provides something to solve this issue? Should I create a separate thread or what?

[mystran]

You don't want to make your own event loop. In fact such an event loop wouldn't even make any sense unless you put your GUI in a separate thread and trying to do so will cause you nothing but endless pain and suffering. On Windows (and macOS for that matter) when you create a window in the host GUI thread, the host event loop will send you events just fine.

That said, you might want regular updates for other things like animation and frankly my suggestion is to just setup a timer (eg. WM_TIMER on Windows, NSTimer on macOS). Hosts tend to be so ridiculously inconsistent about their idle-rates that even if VST3 probably has some idle() function, it's almost certainly not really useful for anything.

[iurie]

You don't want to make your own event loop. In fact such an event loop wouldn't even make any sense unless you put your GUI in a separate thread and trying to do so will cause you nothing but endless pain and suffering. On Windows (and macOS for that matter) when you create a window in the host GUI thread, the host event loop will send you events just fine.

Hi, thank you for your response. You are right, I don't need any event loop or idle interface, I'll receive events from the host main event loop. Being LV2/ Window X mindset, I've confused, Win API behaves differently.

[mystran]

You don't want to make your own event loop. In fact such an event loop wouldn't even make any sense unless you put your GUI in a separate thread and trying to do so will cause you nothing but endless pain and suffering. On Windows (and macOS for that matter) when you create a window in the host GUI thread, the host event loop will send you events just fine.

Hi, thank you for your response. You are right, I don't need any event loop or idle interface, I'll receive events from the host main event loop. Being LV2/ Window X mindset, I've confused, Win API behaves differently.

Right... so on X11 you have a "network" connection to the X server (and I guess the host doesn't really know much about that, so you're stuck polling it regularly), where as Windows the GUI is native and messages are delivered directly to the thread's message queue.

There must still be a message loop for each GUI thread (and in a standalone application you would write one), but the host already has one for it's main GUI thread, so as long as your plugin windows are created in this thread, they will receive messages just fine (well, until host intercepts them, which they often like to do with keyboard events, but that's another story).

The situation on macOS is pretty similar to Windows as well: there's a Cocoa run-loop implemented somewhere by the host and your plugin never has to really worry about it. It's really just X11 that's the outlier here as the X server is an "application" rather than a native facility.

[wrl]

On Linux, it's easier to just spin up a thread to run the UI's event loop. Poll on the X server connection (preferably actually using poll()) and hook in whatever other events you need. Honestly, I prefer it to the Win/Mac model, because on Linux you can get much tighter redraws, and if you're using GL you don't have to worry about blocking in glSwapBuffers() (for vsync) causing issues with other windows.

On Win/Mac, mystran's right. Use a timer event, or, if you're feeling really froggy, you could do CVDisplayLink on Mac (again, for tighter redraws).