Getting Started
SynthEdit's graphics system was recently upgraded significantly, introducing a new concept called sub-controls. Essentially, sub-controls are like building blocks. You use them as components to build customized GUI controls. While this offers unprecedented power and flexibility, it also requires the designer to take time to learn how to use these new tools.
At this writing, the sub-controls are still under development, and official documentation has not yet been released. This document represents my attempt to organize what I have learned so far about sub-controls and how to use them. The sections under the Getting Started heading focus exclusively on the sub-controls that are part of SynthEdit. Later sections will expand upon that, and show how the sub-controls can be even more powerful and flexible when you add the DH_Sub-ControlPak.
The information presented here is accurate to the best of my knowledge. Much of it has been obtained by trial and error, however, and I can't guarantee that I've understood or interpreted everything correctly. All I can say is that this is what has been working for me so far. Likewise, all examples have been tested, and have worked here, but they haven't been tested on other systems. Comments, corrections, and suggestions are welcome.
- Dave Haupt
Yikes! What are all these new connection types?
One of the first things that hits you about SynthEdit's sub-controls, after you get over the shock of the number of new modules to learn, is that you can't connect them to anything!
Well, it's not quite that bad, but there are a handful of new
data types, and techniques for integrating them into the rest of your
SynthEdit projects, that you'll have to become familiar with before you can use them. Here's a brief summary
of the new types:
|
- for any kind of numeric value
- for integers only - for logical values that can be either TRUE or FALSE - for freeform character data - for enumerated data |
Notice that they have blue backgrounds, to distinguish them from the more familiar SynthEdit pins, which have gray backgrounds.
By this time, you've probably already started to wonder why we need Float when we already have voltage pins that handle floating point values, and why there are now two types of List and Text pins. The answer is a combination of factors, including the VST* architecture, efficiency considerations, and, I guess, just SynthEdit history.
Behind the scenes, a VST's audio processing and GUI are provided by separate objects. They communicate with each other, and the host communicates with each independently. The audio processing, of course, has to be performed at the sample rate, so audio data has to be processed constantly at rates like 44100, 48000, or 96000 times per second. The GUI doesn't have to work under the same time constraints. It operates more or less on its own schedule, driven by events such as mouse moves and clicks.
While the original set of SynthEdit data types included both audio processing (voltage pins) and user interface types like Text and Lists, no big distinction was made between audio and GUI data types. In fact, in the original SDK, custom modules had access only to the audio side, and all SDK module pins of all types passed data to and from the audio object.
In the new SynthEdit graphics system, sub-controls connect directly to, and become part of, the GUI side. All text, data, and graphic manipulation for display purposes can be done without involving the audio processing side. (GUI and audio processing are done in separate threads, so in multiprocessing and hyperthreading systems they can be done in parallel. In fact, the system is designed so that GUI and audio processing can even be performed on different machines.)
Connections between the GUI sub-controls and audio-side modules are made through Patch Mem modules. They handle converting between the GUI data types and the original SynthEdit data types. In addition, when you build a control using sub-controls, each Patch Mem module represents one of the control's parameters. You can control:
-
whether or not the parameter will be saved with the patch
-
whether or not VST automation will be used with the parameter
-
assigning MIDI CC#s, RPNs, or NRPNs for MIDI automation of the parameter
This is covered in more detail in the Container Properties and Automation section.
I'm going to call the new blue-background pins "GUI pins", the new data types "GUI data types", and connections between them "GUI connections". The best way to show how to use them is by example. The next few sections will do that, starting with some simple connections.