Introduction:
Sub controls provide a more customized user interface than standard controls but require more expertise to use effectively. They provide a lower-level access to the various visual elements on your control panel.
There are some basic rules that need to be followed to use them with a minimum of problems.
Controls vs. Sub-Controls- Why have Sub Controls?
Before sub-controls, SynthEdit provided only pre-made controls, like the Slider Control. To understand sub-controls, it’s useful to understand how a control works.
For example the Slider:
A slider has several interacting components…
Lets have a look at the custom made slider below. The original SE slider control is included as a comparison (this control cannot be opened up-it’s one of the old ones, (so it can’t be modified without C++ coding).
Moving the slider updates the numeric text readout and vice-versa. So there’s a bi-directional connection between the two sub-components.
Your computer typically updates its graphics 60 times per second yet the output of the is at audio-rate signal (typically 44,100 or more samples per second). So it follows that there’s a rate-conversion happening inside this module.
You can’t open up the original slider to see what’s going on inside, but here’s one I put together to demonstrate what goes on:
The current position of the slider is stored in the patch-memory, and the slider will move automatically to reflect the current patch. We need to find a way of displaying the output value of the control. That’s done with the Float to Text, and the ED Text Entry modules.
The Output from the module can take various forms. Here I have included three types of data that I think I’ll find useful:
1) DSP Volts out, 2) DSP Floating Point out, and 3) GUI Floating Point out.
So you can already see how we can “personalize” and add functions to our controls in this way..
The focal point is the Patch Memory module. This handles the communication between the graphical (GUI) elements (with blue backgrounds) and the audio-processing (DSP) elements (with grey backgrounds).
The Patch Memory module also handles any MIDI Automation of the control and handles switching between any presets (patches).
With the traditional Slider the layout of the elements was fixed. There’s no way, say, to put the numeric readout at the top. But now I have this Sub Control slider I can move the elements around at will. However using the Sub Control I just created then I can modify and move elements around as I like.
The purpose behind Sub-Controls.
The purpose of sub-controls is to split up the control into its constituent parts. As you saw with the slider Sub Control, this is a way of giving far you more flexibility over the appearance of your controls.
The first and focal point is the Patch Memory module. It handles the communication between the graphical elements (on the left with blue backgrounds) and the audio-processing elements (on the right with grey backgrounds). The patch mem module also handles any MIDI Automation of the control and handles switching between presets (patches).
The second type of module here is the graphics controls. The Bitmap Image and the Text entry boxes. These accept user input and display the control’s current value. Graphical elements use the Patch-Mem module as a ‘hub’. Input to any object is reflected back to the others, keeping them always in sync.
The third type of module here is datatype conversion. For example the Text-to-Float module. It’s purpose is to bridge the Patch-Mem module’s numeric (float) value with the Text-entry module (which otherwise would be used perhaps for entering a file-name).
You can see from the arrow heads in the picture below that the GUI Floating Point pins (blue background) are bi-directional. This ties in with the expected behavior.
Updating the numeric-entry box moves the knob and vice-versa. These signals are not sampled like audio signals but are event-driven. Event driven means that the control only sends data and uses the CPU when being moved, at all other times it does nothing. Compared to an audio (DSP) signal, the knob thus generates data at a much slower rate, and only when actually needed.
The signal leaves the Patch-Memory module via the Value Out plug as an audio connection, but it’s still sending data at the slower rate generated by the PC’s graphics system. This is why we include the next stage the Float To Volts module.
The Float-to-Volt smooths out, and up-samples our Floating Point data to a true audio-rate signal suitable for controlling SynthEdit’s various audio modules.
In SynthEdit these audio rate signals are called Voltages because SynthEdit is simulating an old-school Voltage controlled Synthesizer.
The Float-to-Volts module gives you control over how smooth the conversion should be. Less smoothing uses less CPU, but the resulting audio changes (especially with filters) may sound ‘stepped’ or ‘zippered’.
There is another reason this module must be included- without it the data rates will be miss-matched and updates in control position lost resulting in jerky or glitchy changes to the audio modules.
The general structure of a Sub-Control patch is:
[Graphical Control]<—>[datatype Converter]<—>[Patch Mem]—>[Audio modules]
Customizing.
You can see that the numeric input is optional, just delete it if you don’t need it. Same with the rotating knob image. Also you can now place the elements however you like.
Some of the settings available and what they do:
Hint:- Provides for ‘Tooltips’, the popup yellow boxes that appear when you mouse-over the control.
Menu Items and Menu Selection:- Provides a context menu (right-click menu). Type the menu items as a comma-separated list. e.g. “Set to Center=1, Randomize”. These will appear on the context menu, along with SynthEdit’s menu entries.
The ‘Menu Selection’ pin outputs the user’s selection as an integer. e.g. if the user clicks ‘Set to Center’ the pin goes to 1. After any selection the pin returns quickly to zero. Always number your item list from 1 otherwise the first item will always output 0 (which is no different from ‘no-selection’).
Editable:- You can use this with Text Entry boxes to stop uses from changing a label by accident, or to prevent values being entered into a control’s value box.
Greyed:- You can use this with a Text Entry box to indicate that control is not currently relevant.
Efficiency.
GUI Modules:
As you know modules with blue backgrounds are ‘GUI Modules’ (Graphical User Interface Modules). These are designed to process user-input (mouse clicks and text entry etc.). These are not intended to process audio signals. On multicore systems they will usually run on a core separate from the audio processing, this allows the audio modules to take priority when the CPU is under load.
Hybrid GUI/DSP modules:
Modules with both blue and grey pins (like the Patch Memory Modules) are hybrid modules. Internally they consist of two parts running simultaneously in separate processes. Communication between the two parts is complex and is thus more CPU intensive than between other modules.
Don’t use audio modules to process GUI signals
In general aim to keep your use of hybrid modules to the absolute minimum.
For example: Suppose you want to increase a knob’s display to range between 0 and 100, your might think to use the standard Multiplier module. Being an Audio module, this requires an extra conversion via a patch-mem or similar. A much more efficient method is to use a ‘pure‘ GUI solution like the Float-Scaler module.
This will: 1) keep your circuit simpler and 2) your CPU usage far lower.
Use caution with GUI connections into Containers
Sub Controls are only active when the control panel window is open. When you close the control panel, the sub-controls immediately become inactive.
Not only this but GUI plugs communicate only with modules visible in the same window, so if you are passing controls though another container, you must set that containers properties so with the “Controls on Parent” are visible, otherwise the GUI signals will not pass through the container.
This behavior is in support of the new VST3 standards.
Example:- A Knob image is inside a Container, which is connected to a Patch Memory outside the control’s container. Unless the Container is set so that the Panel View is visible the knob cannot not respond to mouse movements and appears ‘frozen’, the Volt Meter and Vector Bar won’t respond to any control movements.
However as soon as we change the relevant settings on the Container – Patch Mem the controls spring into life: (see below)
Note: The structure view will always have this issue, but if the knob’s container has ‘Controls on Parent’ set it will work fine on the Panel view.
The reason is:- With ‘Control on Parent’ set, the knob is displayed on it’s parent container’s window, which the same container the PatchMem is in.
This is confusing- So if possible, always keep your GUI connections within the same container. If you do need GUI connections into a container, you can often get the structure view working too…
For this the container’s ‘Show on Module’ needs to be set. This makes the knob visible in the same window as the Patch Mem which means the data connection works, but there’s still a catch. The right-hand window’s knob still won’t work properly. As it’s effectively a sub-container. There’s no way you can get the Patch Memory module visible in that window.
Summary: Sub controls in a container will work fine on the Panel view provided the container has ‘Show on Parent’ set.
They control may not always respond in the structure view but you can often
(but not always) fix the problem with the ‘Show on Module’ setting.
GUI modules need to be seen
Sub Controls function only while their Container’s Panel is open. i.e. if you close you synth’s panel, those sub controls become inactive.
Therefore never rely on GUI modules to process audio signals. The exception is hybrid modules (Patch Memory) which will continue to provide patch-selection and automation functions via their audio pins.
Avoid splitters
Due to a design mistake, SynthEdit 1.0 had the Container’s ‘Control on Parent’ pin on the wrong side. This made it impossible to connect it to a Patch Mem module (needed for save/recall of paged panel settings).
The ‘Bool Splitter’ was introduced to fix this problem, but the bool splitter causes problems of it’s own. The bool splitter ‘reflects’ any one input signal back out it’s other inputs, this is a bad design because it is not clear which module is in control of the others. The result is modules ‘fighting’ each other for control. Symptoms include ‘flakey’ inconsistent behavior and patches not saved/recalled correctly.
3rd party module developers have sometimes copied SynthEdit’s example and released modules that rely on the use of splitters. This is not their fault, however if at all possible avoid using splitters.
Prefabs worth studying.
SynthEdit’s Insert/Controls menu has several good examples. The Joystick module shows how to make any type of horizontal slider, vertical slider, or two-axis Joystick. Hint: For Sliders – use the resize handles to restrict the area of movement to a narrow strip.
Visual Indicators.
The LED2 prefab is a template for any type of indicator or meter. Notable is it’s clever use of a transparent overlay image to dim the light, and the use of the Tinted Image module to provide for any color light.
Leave a Reply