This is the main version of SynthEdit. Please back up your older SynthEdit projects before using this version.

Requirements

• Requires Windows 7 Service Pack 1 or better. Windows 10 is recommended.
• macOS plugins require macOS 10.8 (Mountain Lion) or better.
• .NET framework version 4.6.2
• Visual C++ Redistributable for Visual Studio 2015.
• A processor supporting multimedia instruction (SSE2). List of supported CPUs.

Troubleshooting

If you are having problems getting SynthEdit to run.

• Install the .NET framework (shown above)
• Install the Visual C++ redistributable (shown above)
• On Windows 7, ensure you installed all available updates.
• Reset the audio driver to "Primary Sound Driver" even if it's already set to that, set it again. (menu "Edit/Preferences").
• Reset the preferences: delete file
  'C:\Users\[yourname]\AppData\Local\SynthEdit\SynthEdit15(x64).settings.xml'
• Sometimes a particular module is crashing SE. To test this, temporarily rename your modules folder 'C:\Program Files\Common Files\SynthEdit\modules' to e.g. 'modules_aside'. If SE no longer crashes, you can identify the problem module by gradually moving modules back to the original folder.

New Features (64-bit version)

• Export 64-bit VST3
• Export Mac Audio Unit plugins.
• Latency compensation.
• Improved oversampling.
• Improved DPI awareness (looks better on Ultra-HD and Retina displays).
• More modules.

Notes:

1 - Since SynthEdit 1.2 modules (SEMs) are stored in two locations:

64-bit SynthEdit:

• C:\Program Files\SynthEdit 1.4\modules - Modules shipped with SynthEdit only.
• C:\Program Files\Common Files\SynthEdit\Modules - 3rd-party add-on modules from other vendors. Please copy your 3rd-party modules here.

32-bit SynthEdit:

• C:\Program Files (x86)\SynthEdit 1.4\modules - Modules shipped with SynthEdit only.
• C:\Program Files (x86)\Common Files\SynthEdit\Modules - 3rd-party add-on modules from other vendors. Please copy your 3rd-party modules here.

Don't copy SynthEdits own SEMs to the common folder (the ones already in C:\Program Files (x86)\SynthEdit 1.4\modules). If you are using SynthEdit 1.1 alongside Version 1.2, leave your existing module folder as-is. Version 1.2 will not access these.

2 - If you experience crashes at start-up this may be caused by a problematic module. Temporarily move your modules folder elsewhere. Then try starting SynthEdit again.

Know Issues:

• To avoid overloading your graphics card (GPU), SynthEdit will open only 5 windows at a time.
• Windows may display a blank area at the far right, or at the bottom. This also saves resources on your GPU for areas you are not working on and not looking at. To see more background just drag any module over by the blank area, next time this window is opened, SE will extend the background grid to include that module.
• Playing the 'Keyboard' module doesn't work from PC keyboard.
• 'Undo' feature causes long delays when editing projects. We recommend you disable 'Undo/Redo' for a faster experience (use menu: Edit/Preferences/General).
• Leaving the SynthEdit 'Power' button (on the toolbar) switched on can cause delays when editing projects. If this is the case please switch the power button off while editing, and on only while you are testing/playing your project.

Known Issues (64-bit)

• The 64-bit version requires 64-bit modules. Most of your older modules are probably 32-bit.  The 64-bit version will load projects created in the 32-bit version, but some modules will be inactive if you don't have a 64-version of them.
• With the VST preset format (*.fxp) presets saved from 32-bit plugins are generally not interchangeable with 64-bit plugins. The exception is that the Preset Browser module can load fxp presets from 32-bit plugins. .fxp presets saved from 64-bit SynthEdit will be compatible with 64-bit plugins but not with 32-bit plugins (and vice-versa).
• xmlpreset format presets are compatible across all plugin formats.
• 64-bit SynthEdit plugins use a new drawing API. 64-bit GUIs (Control panels) do not support all controls, some controls will look different in a VST3 plugin. 64-bit plugins support only images less than 16384 x 16384 pixels in size ( 8192 x 8192 on Windows 7). Fonts may render slightly differently, text is sometimes wider or narrower or smoothed differently.
• 64-bit SynthEdit will export both VST2 and VST Version 3 Plugins. 32-bit SynthEdit will export only VST Version 2 plugins.
• 64-bit Plugins have reduced support for MIDI. Only Note, Controller and SYSEX messages can be received by a plugin, plugins do not currently send any MIDI. Plugins receive MIDI only on channel 1. We will look at increasing the number of supported channels in a future version of SynthEdit.
• The "Embedded files" feature works differently in SE 1.2 (and later), these files are merely copied alongside the exported plugin's other files. The reason for this is Microsoft Windows increased security which prevents files from being extracted from a VST at runtime. This feature has been renamed "Copy Additional Files" to better explain what it does.
• Mac export: Some modules are not available for Mac yet.
• Some modules from the older version of SynthEdit are not compatible with VST3: e.g. Float-Scaler (please replace with Float-Scaler2).
• Oversampling a synthesizer will not work unless the oversampled container contains a Patch-Automator module.
• 64-bit SynthEdit does not support loading VST Plugins into SynthEdit (32-bit does).
• When exporting a VST plugin, SynthEdit copies the required resources (images etc) to the destination plugin's folder. If you then export a different plugin during the same session, SynthEdit will copy the resources for both plugins to the second plugin. To work around this, please close and reopen SynthEdit before exporting a different plugin.

Registering you copy

When you purchase SynthEdit from the SynthEdit website you should receive a serial number via email. To apply this serial:

1. Open SynthEdit
2. Choose menu: Edit/Preferences/Registration
3. Copy and Paste your registration name and serial number into the form. This must be exactly the same spelling and capitalization as you received them.

If you purchased SynthEdit via the Microsoft store you will not need to enter any serial number. You can enter your name on the form. This is used when you export plugins. Your SynthEdit License includes free upgrades up to version 1.9

Where does SynthEdit export plugins?

SynthEdit's "export plugin" feature by default saves plugins to the following locations:

64-bit VST3: C:\Program Files\Common Files\VST3
64-bit VST2: C:\Program Files\VSTPlugins

32-bit VST2: C:\Program Files (x86)\VSTPlugins

Audio Unit: Documents\SynthEdit Projects\Mac Export

Presets: C:\Users\username\Documents\VST3 Presets\Vendor\PluginName\PresetName.vstpreset

You can customize the VST2 plugin location from the Preferences menu. You can not customize the VST3 plugins folder because the VST3 specification says that the VST3 folder location is not optional. 

Will SynthEdit support the export of other plugin formats? (e.g. AAX, LV2, VST on macOS)

SynthEdit is a small company and does not have the revenue to support every possible plugin format. We have chosen to concentrate on the main formats on each operating system (Audio Units on macOS and VST3 on Windows and macOS). The next version of SynthEdit (1.5) has support for 'Apple Silicon' (ARM) hardware, as this is now Apple's primary platform. Version 1.5 will also support 'export as JUCE' which in some cases will allow your plugin to run as other formats that are supported by JUCE like AAX.

Presets

The VST3 plugin format has a new approach to presets. Presets are now stored individually on disk. i.e. They are not stored privately inside each plugin.  This new approach does not mesh well with how SynthEdit has managed presets in the past. For example, the "Ignore Program Change" feature does not work at all in 64-bit plugins.

When distributing your VST3 plugin, you also need to distribute the presets. These can be found in your 'VST3 Presets' folder in 'Documents' e.g. C:\Users\jef\Documents\VST3 Presets\Jeff McClintock\Poly Synth2\Strings.vstpreset

Note that when you export a plugin, the current bank of presets are added to any that were already in that folder. So you might see some old presets in there that you no longer want. You can delete those old preset files.

Also, with VST3 it's normally the "host" (DAW) that has the responsibility of choosing and loading presets. A plugin itself is not required to show any list of presets, nor required to provide any kind of preset browser. It is for compatibility with VST3 DAWs that SynthEdit exports your plugins presets as individual files (*.vstpreset). You usually ship these with your plugin to the end-user.

Despite VST3 plugins not needing to manage presets themselves, we have had many requests for a preset-browser that works in VST plugins.  To help with these issues, SynthEdit 1.4 has a new module, "Preset Browser", that can browse VST presets on disk. This module also allows you to categorize presets into groups of similar presets. It can also load and save presets in several formats.

Using the Patch Browser

The simplest way to use the patch browser is to connect a Popup Menu module, this will not only list the available presets, but also group them into categories (if you are using that feature).

Alternately you can create a patch browser using List Box modules. The Menu-to-Listboxes module can be used to separate the categories and presets into two lists.

Setting categories

Each preset can be tagged with a category. To set the categories on presets, hook up a Text Entry sub-control to the Preset Browser as below. In the Text-Entry3, type in a category.

Loading and Saving presets

To give the end-user control over the loading and saving of presets from disk, hook up a Popup Menu module like so...

Sharing presets between different plugin formats

To convert presets between the various different preset formats like *.vstpreset and *.aupreset, SynthEdit offers two generic formats, the 'XML Preset" (*.xmlpreset) and the "XML Bank" (*.xmlbank) which can be used to move presets between SynthEdit, Audio Unit plugins, and VST plugins. This format is also a plain-text format, so it provides the opportunity for power-users to tweak the presets manually if you wish.

Note: When exporting banks, SynthEdit will avoid exporting blank presets by exporting only up to the last named preset. Presets with blank names after that will not be exported. To blank out preset's names in bulk, use the "Copy Preset" feature to copy a blank preset.

Note: When importing banks to VST3 plugins, the presets will be written to disk as individual files (one per preset). The has the side-effect that when the plugin scans the presets, the presets will end up displayed in alphabetical order (not the order they were saved in). Despite this, you can use preset categories to group related presets.

Presets in VST2 Plugins

  The VST2 plugin standard requires plugins to hold presets internally and provide the list of presets to the DAW.  To aid this, when saving 64-bit VST2 plugins SynthEdit stores all presets from your project as "Factory Presets" inside the plugin.
   In VST2 plugins the  "Patch Browser" module behaves differently: It presents a list of the internal (factory) presets, but in addition adds any external preset files (in the *.vstpreset format). This allows the user to choose from both factory-presets and user-saved presets. If the same preset name exists in the factory list and on disk, only the disk-based preset is shown. This prevents double-ups from appearing on the list.

Distributing Soundfonts, Wave, and MIDI Files

Often a VST needs to load Soundfonts automatically. For example, your VSTs may use Soundfonts as built-in waveforms. On the end user's PC, these Soundfonts need to be installed in the plugin folder.
Example:

VST plugin:	MySynth.dll
Soundfont:	Drums.sf2

VST path:	C:\Program Files\Common Files\VST3\MySynth\MySynth.vst3
Soundfont path:	C:\Program Files\Common Files\VST3\MySynth\Drums.sf2

The Soundfont is in the same folder as the VST Plugin. Ideally, you would create an installer that copies both VST and Soundfont to the customer's hard drive.

Relative Paths

Since you don’t know the end user’s plugin folder, store Soundfont filenames as a relative path. A relative path does not contain the full Drive or folder specification, e.g. "C:\SomeFolder\".

 Before you hit 'Export-as-Plugin' check your Sample-Player module is using relative paths. Select the module. Locate any filename parameters (e.g. ‘Sample Loader2 Filename” ) on the Properties panel (at far right). Check if the ‘Value’ column contains a 'relative' filename like “Drums.sf2”. If it contains folder references ( like “C:\Samples\Drums.sf2) you need to remove the drive and folder parts. i.e. change it to just "Drums.sf2".

Simplifying the filenames can prevent them from loading in the SynthEdit editor because SynthEdit no longer knows what folder they are in. You can either ignore these warnings and revert the filenames after you have exported the plugin, or put the Soundfonts in SynthEdit’s default audio file location. Look in the menu "Edit/Preferences/File Locations/Audio Files" for this folder. This is where SynthEdit looks for files with relative filenames.

To have SE automatically use relative paths - You must set your default audio folder before you load the Soundfont, not after. Otherwise, SynthEdit will use the full path. Alternately: set the default audio folder, then un-load the SoundFont, then re-load the SoundFont.

Upgrading older projects

Newer versions of SynthEdit will generally open projects made with an older version. However, if you encounter problems loading files from Versions earlier than 1.1 please try loading and saving it into SynthEdit Version 1.1 first. SynthEdit 1.1 is better at upgrading very old project files. Once the project is upgraded to 1.1, it should upgrade further OK.

Registration System for your Plugins

The "Registration Check" module allows you to provide a basic system to register users of your plugins. The idea is you issue each user with a serial number. The serial is linked to the user's name (or email).

Use two "User Setting - Text" modules, one to save the user's name, and a second to store their serial. This data will be stored on disk and recalled any time the user loads the plugin. Each User-Setting-Text module needs a "key" which identifies what the setting is called. On the first User-Setting module, set "Key" to "Registration Name" or similar, and set the second module's Key to "Serial" or similar. (Ref to the diagram below).

Registration Setting will be saved to the following folder:

C:\Users\UserName\AppData\Local\ProductName\Preferences.xml (Windows)

~Library/Preferences/ProductName/Preferences.xml (MacOS)

In the below example a LED is used to indicate a valid serial number. In practice, you might choose to use this signal to restrict the features of your instrument, or to add periodic noise bursts etc.

To generate serials, use the " Registration Serial Generator" module (don't share this module with your end-users). Ensure you enter the same "random seed" into the Registration Serial Generator that you used in the Registration Checker. The seed should be different for each of your plugins (else the same serials will activate all of them). Currently, it's necessary to generate each serial manually.

Ensure you enter a unique product-name into the User-Setting-Text module otherwise the system will mix up serials from different products. The "Default" setting is not important, it can be left blank.

New Graphics Code

Older versions of SynthEdit were tied tightly to the Windows Platform. With the introduction of Mac support, SynthEdit needed a new graphics layer that worked on both Windows and Mac OSX. SynthEdit 1.2 introduced this new API called "GMPI-GUI". The new API is "virtualized", that is module developers need to write graphics code only once, and this code is portable to any operating system.

This new API takes advantage of improvements in graphics technology by building on top of Microsoft DirectX. Graphics are now smooth (anti-aliased), fast (hardware accelerated) and resolution-independent (looks good on "retina" and "ultra-HD" displays). To ease the learning curve, and to reduce the overheads of virtualization GMPI-GUI's API is very similar to Microsoft Direct-2D. On Mac OSX, GMPI-GUI translates Direct-2D commands into the Mac graphics API (Core Graphics).

Currently, GMPI-GUI is enabled only in 64-bit plugins. Working in SynthEdit you will still see the old graphics rendering. This provides excellent compatibility with your existing projects but can be confusing when your 64-bit plugin ends up drawing slightly different than it did in SynthEdit.

SynthEdit 1.4 consolidates all drawing onto GMPI-GUI which will improve the performance of scrolling and animation in SynthEdit. It will also enable new features like zooming in and out on your project.

SE Version 1.3 Does not understand "ultra-HD" monitors (aka "retina" displays). These are displays with more pixels than standard HD (high density). Also known as High DPI monitors. The result is the GUI within SynthEdit 1.3 will look half the size that it does in a DAW like Cubase.
  SynthEdit 1.4 rectifies this issue. The Graphics in SynthEdit 1.4 will look exactly the same when exported as a VST plugin.

More about Direct-2D

https://msdn.microsoft.com/en-us/library/windows/desktop/dd370987.aspx

https://www.youtube.com/watch?v=HGokM9AikzM

Unable to write VST plugin folder

By default, Windows does not allow saving files to your VST Plugins folder. This prevents SynthEdit exporting VST plugins. You can fix this by changing the folder's Permissions:
- Use Windows Explorer to browse to your VST Plugins folders. These are usually:

• C:\Program Files\Common Files\VST3
• C:\Program Files\VSTPlugins

- If the folder does not exist, create it.
- Right-click the folder - 'Properties'
- Choose 'Security' tab.
- Click 'EDIT' (You may need to click a UAC security prompt).
- Select username "Users".
- Tick options Allow 'Write' and 'Modify'.
- To finish Select 'OK' to close the two dialog boxes.

"Poly to Mono" module

This module converts a polyphonic signal to mono by splitting off only the most recent note played. The output will be similar to a monophonic instrument. This is useful when trying to modulate a monophonic object (e.g. an LFO) from a polyphonic signal (e.g. note-pitch), which is usually not possible in a meaningful way.

"Voice Combiner" module

This module mixes-down a polyphonic signal into a monophonic signal that includes all voices that are playing.

Registering SynthEdit bought in the Windows Store

If you bought SynthEdit in the Windows App Store, you won't need the usual 'unlock' serial number, but you will need to enter your name and email in the Registration screen (menu 'Edit/Preferences/Registration". This information is used to identify any plugin you make.

Plugins Reset In Certain Conditions

Plugins made with SynthEdit sometimes need to reset. This causes a short pause in the audio, it kills any sounding notes, and resets MIDI controllers to zero. The reasons a plugin might need to reset are:

• Changes to the plugins oversampling settings
• Changes to the plugins latency settings
• Adding or removing patch-cables
• The polyphony has increased
• A preset change has indirectly caused one of the above to change
• Changes to the DAW sample-rate

These are events that cause modules to be added or removed from the signal chain, which in turn forces SynthEdit to recalculate the entire signal chain and is not something that can be done in real-time.

Future Development

Future versions of SynthEdit (e.g. Version 1.5) will drop support for 32-bit Operating Systems. This is in line with industry trends.

There are currently no plans for VST support on macOS (only Audio Unit plugins). This is due to SynthEdit being a small company, we don't have the resources to support every plugin format on every operating system.

Fixing Text Alignment issues

Older builds of SynthEdit suffered from inconsistent text drawing on Mac. Mac plugins would draw fonts slightly higher or lower on the screen than the same Windows plugin. This problem is now fixed. However, the fix needs to move your fonts slightly, so the fix is opt-in (i.e. SynthEdit will not adjust your fonts unless you ask for it).

To get the fix in your instrument’s skins, modify your ‘global.txt’ file (it’s in your skin folder. Right-click the Panel view, choose 'Skin/View Skin Files...'). Add the line “legacy-vertical-offset 0” to each category in your skin folder as below. Remove any lines beginning with 'vst3-vertical-offset' - this is an older fix that was not very useable. This will enable the fixes and disable the old behaviour. (see the skin called “default2” for an example of this). You will need to restart SynthEdit to see the changes. You will then need to check the alignment of all you controls and fix any that have moved.

In my example, I also changed all fonts to be ones that are available on both Mac and PC, like Arial, Courier New, and Times New Roman. However, if SynthEdit can’t find the font you specify, the fix will now substitute fonts of exactly the same height, so at least the text will still sit with the correct vertical alignment and not be too high or low like before.

The only remaining difference with font rendering is that the Mac renders fonts a little heavier in weight, but that behavior affects all apps on Mac, not only SynthEdit.

 

Latency Compensation

Some types of signal processing introduce an unwanted time-delay to an audio signal. This unwanted delay is called 'latency'. Latency is not to be confused with deliberate time-delay e.g. reverb and echo plugins. 

Examples of processing that introduces latency include spectral effects, look-ahead limiters, oversampling, and sometimes filters. This latency is a side-effect of the processing, and we would prefer to experience the effect without any unwanted latency. 'Latency Compensation' aka PDC (Plugin Delay Compensation) is a method of hiding this unwanted latency.

How does Plugin Delay Compensation work?

Plugins can report their unwanted latency to the host DAW. The DAW can then compensate for this by time-shifting the audio on the plugin's track. Shifting a track's playback earlier in time can compensate for a plugin that adds latency to the signal. The result is as if the plugin added no latency. Note that latency compensation works only on pre-recorded material, it is not possible to time-shift live audio. For this reason, you will sometimes hear latency from your DAW when you are monitoring a track while recording it, but not hear latency later when you playback the track.

SynthEdit modules that produce latency include the 'Sinc Lowpass Filter', the 'Sinc Highpass Filter', and the oversampling system. These modules report their latency to the SynthEdit plugin runtime and SynthEdit plugins in turn can report that latency to the DAW.

You can enable and disable this latency reporting when exporting your plugin from SynthEdit. The options are 'Off', 'Full' (On) and 'Constrained'. 'Constrained' means that the plugin will compensate for latency up to a point (5ms), but not more. This prevents the user from experiencing too much latency when monitoring a live audio signal or instrument. Too much latency makes it difficult to play a software instrument with good timing. 5ms is enough compensation for most situations anyhow. 'Full' compensates latency up to 1000ms. 'Off' does not compensate for latency at all.

 

Latency and 'Feedback (Delay)' modules

SynthEdit's Feedback modules do introduce latency but the output of these modules gets mixed with regular (not-latent) signals. So It's not possible to reconcile the mixture of two signals with different latency. For this reason, the feedback modules report zero latency.

Latency and Oversampling

When you oversample SE has to run the audio through an upsampler and later a downsampler, these introduce latency (a delay) to the signal. If for example you then tried to mix the “dry” (not oversampled) signal with the oversampled signal you might get an unwanted phase cancellation (likely causing a phasing effect). You can enable latency compensation to fix this problem. What latency-compensation does is delay the “dry” signal to match the latency on the oversampled signal. The result is as if the oversampler had no latency, i.e. no phasing artifacts. In a plugin, the latency compensation is reported to the DAW, which can then time-shift the track slightly to hide the latency. The end result is a plugin with “perfect” (apparently) zero-latency oversampling.

Other notes

Routing around latency in a project does not eliminate the latency (e.g. adding a 'bypass' switch). SynthEdit will simply add latency to the alternative route to compensate (so they can be mixed back together correctly).
SynthEdit will recalculate latency when you delete or add patch-cables on the panel. Latency also does not apply to muted modules, they are treated as having zero latency. But modules can only be muted in the editor at present.