PLUG'N SCRIPT
rapid plugin development
Tutorial
DSP
KUIML
How-to
Scripts
Introduction
  • How plugins work
  • Plug'n Script evolution
  • What can I do with it
  • Pros and cons
Quick start
  • Interface overview
  • Writing a simple script
TutorialHow plugins work
August 02, 2026

How VST (VST3, AU, AAX) plugins work

When you start making a plugin with Plug'n Script, it's important to understand that a plugin is not a single monolithic application. Instead, it typically consists of two (or more) separate parts that run independently and communicate with each other.

  1. The part that processes audio or MIDI — the DSP (Digital Signal Processing).
  2. The part you see on the screen with controls, knobs, meters, etc. — the GUI (Graphical User Interface).

In some plugin formats these parts are more tightly integrated; in others they are more separated. Plug'n Script abstracts away the underlying plugin format, but the same separation generally applies.

DSP

The DSP part runs whenever the DAW calls it. The main function the DAW invokes is processBlock, which receives the current block of data (audio samples and/or MIDI), processes it, and returns it to the DAW. The size of this block (in samples) depends on the buffer settings (for example, ASIO) chosen by the user. For instance, with a buffer size of 1024 samples at a 48 kHz sample rate, the DSP's processBlock function is typically called about 46–47 times per second. (*Some DAWs may split audio buffers into smaller chunks during automation or under other conditions; in that case processBlock will be called more often).

The DSP must be fast and efficient because a DAW project usually runs many plugins. It must not be blocked by the GUI or other time-consuming operations such as memory allocation, synchronous disk access, or network I/O. The DSP should be independent and as quick as possible: grab the block of data, process it, return it, and wait for the next block.

Just a note

The Plug'n Script API also provides other functions that are called regularly (often from within the processBlock call). For example, updateInputParametersForBlock is called when an input parameter changes so processing variables can be recalculated using the new values.

GUI

The GUI runs when the user opens the plugin window. The GUI should be responsive; when the window is closed and the plugin runs in the background, the GUI in Plug'n Script is effectively "inactive" and does not consume CPU.

The GUI and DSP in PnS communicate using parameters (floating‑point values) and strings (text data). Plug'n Script supports by default 48 input parameters (used to send data from the GUI to the DSP; these can be mapped to controls such as knobs and sliders), 32 output parameters (used to send data from the DSP to the GUI, e.g., levels or gain reduction meters, visible in the DAW as OUT:ParamName) and 32 private output parameters (the same, but not visible in the DAW). Input parameters can be automated and recorded by the DAW. The number of input and output parameters can be increased using a config.ini file, and is unlimited when the plugin is exported.

There are also by default 16 input and 16 output strings (can be increased by config.ini) that can transfer larger chunks of data between the DSP and GUI. For example, you can send large blocks of data from the DSP to the GUI using output strings. Input strings also provide an alternative way to send extra data from the GUI to the DSP (though string data cannot be recorded or automated by the DAW).

Keep in mind

When you change a parameter in the GUI (for example, turn a knob), the DSP does not receive the new value instantly, and the reverse is also true. The GUI and DSP access the data model independently and are not perfectly synchronized. The update is usually fast (depending on block size and other factors), but not instantaneous.

That is basically how these parts communicate.


Comments

Please, authorize to view and post comments.

2020 - 2026 © Site by LetiMix · Donate  |  Plug'n Script and KUIML by Blue Cat Audio