TIP: Using the Zoom in function: (V1.5 only)
In both the structure and panel view, you can zoom in and out of the view by holding down the CTRL key and using the mouse wheel. Amongst other things it can make it much easier to select the nodes on the cables between data plugs.
Even that pest of a node “hidden” under a cable can be selected and moved when zoomed in. Last but by no means least you can see complex wiring better.
TRAP: 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 continue to provide patch-selection and automation functions via their audio pins.
TRAP: 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 bigger problems of it’s own. The bool splitter “reflects” any 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 odd and inconsistent behavior, along with patches not saved and/or recalled correctly.
Note: Some third party module developers have in the past 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.
TRAP: Connecting Patch Memory to Patch Memory.
Do NOT do this, it will cause data and Preset conflicts. If there are other modules in between the two Patch Memories that’s fine, but a direct connection is a complete non-starter.
TRAP: Don’t connect the Polyphony module to a Patch Memory.
The Polyphony module is a type of Patch Memory module. Connecting a Patch Memory to a Polyphony Module will cause huge problems with Data conflicts. However much you think it might be useful DO NOT DO THIS.
TRAP: Don’t use audio modules to process GUI signals.
You should always aim to minimize your use of hybrid modules.
For example: Suppose you want to increase a knob’s display to a range between 0 and 100 (without actually altering the output value, your might think it’s an idea to use the standard DSP Multiplier module. Being an Audio module, this requires an extra conversion via a patch-mem or similar module. It’s far better to use a ‘pure’ GUI solution like the Float-Scaler module. This will keep your circuits far simpler and your CPU usage much lower.
The WRONG method of doing the Math conversion:
Never do this, it’s wasteful of resources, needlessly complicated and uses far more modules than you need (and can introduce Float conversion errors).
The correct method:
This is much simpler, doesn’t use needless GUI -> DSP -> GUI conversion, and uses far fewer resources. It’s also (I think you’ll agree) much less complicated.
TRAP: Don’t use GUI modules to process Audio (DSP) signals.
There are some very good reasons for this:
1) GUI modules use a different CPU “thread”, and run at a slower rate than their DSP counterparts to save on CPU usage. This will cause audio dropouts and errors of all sorts.
2) It’s very inefficient and wastes CPU resources.
3) A GUI module in a container will not pass audio if the container is not open when the VST is in use- your VST won’t work properly.
The only GUI modules that can be used with DSP are the Patch Memory modules- they are designed to work reliably.
TRAP: Don’t make structure changes when the Audio Engine is running.
It’s a known problem that making changes to the wiring, adding certain modules or replacing modules when the Audio Engine is running can cause crashes. Either SE will completely freeze, or will just shut down with no warning.
There is no autosave!
TRAP: Windows Default Fonts.
When using fonts in SynthEdit make sure you use the windows system fonts. However much you’re tempted by a fancy LCD or 7 Segment style, or a futuristic looking font- do not use it unless you are rendering it as a graphic file. If the end user doesn’t the same font on their system at best you will get a substituted font that looks vaguely like your original, or is totally different in style and size.
Safe fonts for Windows are listed on this web page
Safe fonts for MAC are listed on this web page
Crashing: SynthEdit V1.5 keeps crashing for no apparent reason.
If you have persistent problems with SynthEdit crashing, make sure you have the latest build (check here for the latest update)
Open the Edit->Preferences option and select the General tab. Make sure that the options Disable Hardware Graphics, and Disable Deep Colour Swapchain are selected. This stops SynthEdit from using dedicated GPU memory, and reduces the memory usage by the graphics. This can solve the problem in quite a few cases where low-end GPU cards are in use. There are known issues with some Intel GPU’s and their drivers causing problems with SynthEdit.
Also it can help to include an Sound Out module in every project if you’re going to turn the Audio Engine on.
ASIO Drivers.
If you have a soundcard that supports ASIO, it’s best to used a dedicated ASIO driver supplied by the OEM. ASIO4All is not recommended as it’s just a generic driver, not soundcard specific.
This is not a confirmed problem but I have personally had issues with the Behringer Soundcard ASIO drivers causing SynthEdit to crash with no error logging.
TIP: Saving CPU – cut down on un-needed modules.
The structure below might seem a good way so have a volume control in your Synthesizer. Up to a point it is, but there’s a much simpler way of doing it.
The method below however uses one module less. Any module that generates or processes audio signals will use more CPU than a module that doesn’t.
Signals originating from sliders, knobs, and any other data that doesn’t change very often, like the MIDI to CV modules Pitch and Velocity outputs, the output signals of controls can be considered control signals which use less CPU power.
They are only really using power when you change a control position.
An envelope generator module is somewhere in-between DSP and GUI in it’s mode of operation; during its Attack and Decay segments, it’s generating audio rate data, during the sustain section of the envelope, it’s generating a flat-line, control-rate signal.
1) Adding modules to the control path is often cheap or even free. However this does not mean use GUI modules to do the work of DSP modules.
2) Adding modules to the audio path is expensive in terms of CPU usage.
The correct method of controlling the volume is to use the Overall Level plug on the ADSR2 module. But you say, I want to use the output of the ADSR to sweep the cutoff of the filter. Well most Synthesizers have a dedicated ADSR for the VCA, and another for the filter or any other modules that deed an envelope modulation, and that one can be controlled in the same way.
Each patch cord that routes audio signals in SynthEdit represents an audio buffer of around 100 samples (that’s 400 bytes of memory), so this final version not only saves 44,100 math calculations every second; it’s also saving a further 88,200 sample copies per second by using less patch cords.
Keep those structures simple.
Remember: Each DSP module, and each DSP patch cable is eating up CPU cycles!
Always look for a way to use fewer modules and patch cables.
Always think K.I.S.S: – Keep It Simple Sir.
TIP: Downloaded Third Party modules don’t show in the browser.
This is not a bug, this is due to the way windows treats files containing executable code that have been downloaded from the Internet. In some cases windows deems them a security risk, and blocks them from being scanned by SynthEdit. Right click on the module in question and you’ll see a properties option, click on this and this window will pop up:
To allow SynthEdit to scan the file check the Unblock box, and re-scan the files.
Leave a Reply