ASPiK SDK
Loading...
Searching...
No Matches
Creation & Communication

Custom View Creation
VSTGUI has a built-in mechanism for identifying GUI objects in the XML description files as requiring custom view creation. An attribute named custom-view-name stores a string that identifies the object. During creation, the VSTGUI object class factory normally reads the XML file and generates the appropriate GUI object as specified. The PluginGUI object is given the first chance of creating the GUI objects during a function call to a view creation method. That method decodes the custom view name, constructs the custom object (which must ultimately derive from VSTGUI::CView), and returns a pointer to the object. It is during this function call that we have a chance to create a communication mechanism to a custom view object. The PluginGUI object uses an interface passed to it upon creation to register each custom view that it encounters out of the XML file when the user opens the GUI.

During the registration process, a pointer to an ICustomView interface is sent to the plugin shell. The plugin shell object (which creates and destroys the PluginGUI object) will maintain a list of ICustomView interface pointers that are registered with it and will supply the PluginCore with a persistent set of ICustomView interface pointers during the following custom view registration message that is sent to the PluginCore. In this way, once the plugin core has a registered ICustomView pointer, it will be guaranteed to be valid and persist for the lifetime of the PluginCore, regardless of the user’s opening and closing the GUI. So, the PluginCore never holds an actual pointer to a PluginGUI object or interface, and never has to worry about an ICustomView pointer ever becoming invalid or going out of scope.

This ICustomView interface will allow your PluginCore to send data to the custom view in a safe manner.

Custom View Communication
The fundamental difficulty in communication between the plugin and custom view is in implementing a thread-safe communication system that connects them. There are multiple solutions to the issue and ASPiK uses lock-free ring buffers to send audio data and messages to the custom view objects. The figure below shows the detail from Designing Audio Effects Plugins in C++ 2nd Ed. that shows the ring buffer system. The black dots represent audio samples.


The PluginCore receives audio samples via the processAudioFrame( ) function. For both the waveform histogram and the spectrum view, we will pump all of the incoming audio samples into a ring buffer which will store copies of the data. This happens during the audio thread’s time slice.

The GUI is running on a timer that updates it visually every 50 mSec - this is the standard VSTGUI mechanism. The PluginCore delivers data into the custom view using its ICustomView interface pointer during a GUI update ping, called from the GUI thread. It removes all of the samples that had been used into the ring buffer and sends them into the custom view, which then pushes them into its own lock-free ring buffer. During the drawing update cycle, the custom view then dequeues the data in the ring buffer and draws with it.

It should be noted that the use of the second ring buffer on the custom view object is redundant for ASPiK, where the GUI timer ping message and window invalidation (repainting) are synchronized together. However, that might not be the case for some other (non-ASPiK) plugin framework so we add the secondary ring buffer as a backup safety measure.