Forgot to say how to use it:

Use drag and drop of one or several folder(s) with audio files.
click with the left or right mouse button to switch from one plugin to another (when plugin is enabled, or it will change the background).
To move from one song to another press on the auto/hide arrow (sprite object).
To move within the song use the small yellow animation seek pointer.
To adjust the audio level click on the dot line above the word BASSBOX.
You can setup the equalizer from the popup menu.

BB64 was my first real GDImage/WinLIFT 64-bit application ever written in C++ with Visual Studio.

WM_COPYDATA is a high priority message.

Here is the complete BB64 VS2010 project, altogether with the PowerBASIC bridge code (BBP.bas)

No, I can't agree with that statement. Everything that's based on the window message processing pump is turtle slow, computation wise. That's because MS Windows has got its own idea of task priorities and tends to block and kill the apps that don't agree to play by its rules.

BTW where's that:

Note: The source code is provided to help those wanting to learn more about low level SDK programming in C++, and to get the most of WinLIFT and GDImage.

? ? ?

I can't notice any perceptible lag between the sound and visual response via WM_COPYDATA.

The whole Windows paradigm is based on the message pump, and sendmessage is the basic and fastest way to use for IPC.
And the WM_COPYDATA message has a high priority.

I can't notice any perceptible lag between the sound and visual response via WM_COPYDATA. I think such a speed of data interchange will be sufficient for "slave" OR's real time response to the model data changes in the "master" editor application.