Spread the love

What is a SynthEdit container?

A container is a special type of module that can contain other SynthEdit modules (much like a folder contains files), they can be used to contain all the modules performing a specific function, such as a custom built control using sub controls. Using a Container keeps all the modules in use by this function grouped together making for neater, easier to understand plug in design structures.
To see all the modules and patch cords inside a container open its structure view by double clicking the top of the module.
Connections into and out of the container are handled by an IO Mod module. SynthEdit will automatically add an IO Mod module when a container is created, however you can add more if you wish so that you can keep inputs, outputs and controls separated.
Open the containers Panel View (right click- Panel Edit) to see the user controls inside the container, or you can display the controls on the module itself by enabling the Containers Controls on module in the properties panel
Using containers will not generally harm efficiency. Audio doesn’t actually travel through the IO Module, but goes directly to the correct destination.

Left Hand Side

-> Visible:- Determines if any controls inside the container will be visible in the main panel. This can be used to switch between control panels, and hide controls when they are either irrelevant, or not required (I.e. for advanced and basic control panels, or hiding a sequencer when not in use ).
Important note: if there are GUI modules in the container that are essential to the operation of your Synth/Effect this container must always be visible for the Synth/Effect to work correctly. Never, and I really do mean never put GUI and DSP modules in the same container if the Synth relies on the DSP modules!
-> Inputs:- (In this case MIDI In) – Variable – Depends on the internal structure of the module, and any external connections.

Right Hand Side:
<- Outputs:- (In this case Trigger, Gate etc.) Variable – Depends on the internal structure of the module, and any external connections.

Locking Containers (V1.4 only).
Containers are marked with an icon that also shows if the container’s structure and panel views are locked for editing. As well as the change in padlock icon to red, any “Spare” plugs will also be hidden. You can still add modules, change parameters, and use the controls in panel view, but you cannot delete anything, or change the panel layout once it’s locked.
Note: In V1.5 the lock icon never appears as only the panel view is lockable.

1) Allow the grouping of a synths functions into easy to manage groups of modules. For example, the filter and LFO sections of a synth.
2) Containers are used for controlling SynthEdit’s polyphonic behaviour

Containerizing existing modules.
You don’t need to add an IO Module to the structure SE does this for you as soon as you “containerize” your modules.

Creating an empty Container.
Just create the Container as you would any other module, when you open it you’ll find one IO module inside, you can add others for outputs, controls etc.

NOTE: If you intend to use several independent synths in a project, each one must be inside its own container.

NOTE: If you use modules that have a default value internally set to one of the plugs, such as the Level Adj module inside a container, and connect these to an IO Module the IO Module’s Plugs will then take on this default value, which in the case of control voltages can cause unwanted offsets. (See below)


The internal structure of the Container is above, and as you can see the Rectifier and Inverter inputs read 0 volts in the properties, whereas the Level Adj1/2 inputs read 8 volts. In some structures this could lead to you ending up with an unwanted 8 Volts offset on a control voltage.

SynthEdit Sub Controls are only active when the control panel window is open. When you close the control panel, the sub-controls become inactive.
Note: GUI pins will only communicate with modules visible in the same window.
This behaviour is to support the new VST3 standards.

Example: – You have a Knob image which is inside a Container, connected to Patch Memory which is outside the container. The knob cannot respond to mouse movements and is ‘frozen’. It’s usually only the structure view that experiences the issue, 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, the same container the Patch Memory is in.
This can be confusing – So whenever possible, confine your GUI connections within the same container.

Sub Controls function only while their Container’s Panel is open. i.e. if you close you synthesiser’s control panel, those sub controls become inactive. Therefore you must never rely on GUI modules to process audio signals (there are other very good reasons too). The exception is hybrid modules such as Patch Memory which continue to provide patch-selection and automation functions via their DSP plugs.

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 Memory 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 ‘flaky’ inconsistent behaviour 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. If at all possible avoid using splitters.

Don’t cut and paste them from another part of the structure, as they will retain their old values, and it may be extremely difficult to remove these values, or you’ll get unpredictable behaviour. Patch Memory modules retain the last lot of values they received from the connections they had to the modules in question. Well after all they are called memory modules.

It may seem like a good idea to use a Patch Memory Text Out module, and a Text Entry4 module to allow you to change the name on a control held inside a container.
After all you can just edit the text in the containers properties, and it will them be retained for all time can’t you?
Well yes it will work, but you’ll find that the text will not display if the audio engine isn’t running, it will be OK in the VST, but not in Synthedit.
Also if the Prefab in the container was given text labels when it was created and you want to change them it may well give you a hard time updating them (see above). It’s a little unpredictable, and if you copy and paste the modules the text in the labels can get you into quite a tangle trying to sort it out.
You have been warned.
Another method is to put a Text Entry4 module in the container with no connections, untick the “Writeable” property and when you want to label the control open the container and edit the text from there, it will still be retained until you change it.