# logue-sdk: building custom DSP for Korg's open synth hardware > logue-sdk is Korg's SDK for writing custom oscillators and effects for the prologue, minilogue xd, the Nu:Tekt NTS-1 and NTS-3 kits, microKORG2 and drumlogue, with per-platform project templates, a dockerised build environment and a browser-based simulator. Two incompatible unit formats exist, so the target hardware decides the ABI you build against. **korginc/logue-sdk** — This repository contains all the files and tools needed to build custom oscillators and effects for the prologue synthesizer. - Repository: https://github.com/korginc/logue-sdk - Website: https://korginc.github.io/logue-sdk/ - Stars: 1,050 · Forks: 362 - Language: C - License: BSD-3-Clause - Published: 2026-10-19 · Updated: 2026-10-19 · Language: en - Canonical page: https://hysenlabs.com/projects/korginc-logue-sdk ## Two unit formats, and the choice is the hardware's The compatibility table in the README is the most useful thing in the repository, and it is the first thing to read. The prologue, the minilogue xd and the Nu:Tekt NTS-1 digital kit all use SDK version v1.1.0 and require firmware at or above v2.00, except the NTS-1 digital kit which needs v1.02 or above. Their unit format is a custom 32-bit LSB executable, ARM, EABI5 v1 (SYSV), static, on an ARM Cortex-M4. The newer instruments use a completely different scheme. The drumlogue, the Nu:Tekt NTS-1 digital kit mkII and the Nu:Tekt NTS-3 kaoss pad kit all use SDK v2.0.0 with firmware at or above v1.0.0, and their unit format is an ELF 32-bit LSB shared object, ARM, EABI5 v1 (SYSV), dynamic, on either an ARM Cortex-A7 or an ARM Cortex-M7. The microKORG2 sits alone on SDK v2.1.0, firmware v2.0.0 or above, on an ARM Cortex-A7. So there are two ABI families, not one. A static custom executable is not an ELF shared object, and a Cortex-M4 target is not a Cortex-A7 target. A unit written for one family will not load on the other, and the choice is made by the instrument, not by you. The README also states the compatibility that does exist. User units built for the prologue, minilogue xd and the NTS-1 digital kit, mkI only, are binary compatible with each other as long as the SDK version matches. But developers are encouraged to optimize their units for each target platform, and specialized builds should be preferred if available. That last sentence is the practical guidance. Binary compatibility is a fallback, not an invitation to skip per-target optimization. ## One platform directory per instrument The repository structure is organised by target, and the layout is the documentation. There is a platform/ directory with one subdirectory per product: platform/prologue for prologue specific files, templates and demo projects, platform/minilogue-xd, platform/nutekt-digital for the Nu:Tekt NTS-1 digital kit, platform/drumlogue, platform/nts-1_mkii for the mkII, platform/nts-3_kaoss for the kaoss pad kit, and platform/microkorg2. The naming is not uniform, which reflects the fact that these are separate product lines added at different times rather than one unified target set. Each directory holds the files, templates and demo projects for that instrument. The template is the practical entry point, because a project for a given instrument is not a free-form build but a scaffold with the right linker script, startup code and build rules already in place. There are three supporting directories. platform/ext holds external dependencies and submodules, which the.gitmodules file at the root tracks. tools/ is the installation location and documentation for the tools required to build projects and manipulate built products, and the README notes it can be ignored if you are using the docker container. devboards/ holds information and files related to limited edition development boards. Two root files are worth knowing about. developer_ids.md and factory_unit_ids.md, which are the identifier files. The presence of both developer and factory identifiers tells you the SDK expects you to work with the unit identification model that the firmware uses, where a unit is a known vendor, a known product and a known unit id, which matters when you want a unit to be recognised as a factory unit rather than a user unit. There is also a Japanese version of the README at README_ja.md. ## The docker image solves the host toolchain problem The docker/ directory exists because building a Korg unit requires a specific cross-compiler toolchain, and that toolchain does not install cleanly on every host operating system. The README describes it as sources for a docker container that allows building projects for any platform in a more host OS agnostic way. That is the entire value proposition, and it is a real one. Embedded toolchains are the classic case where a developer laptop differs from a build server, and where a version mismatch produces errors that have nothing to do with your code. The practical consequence for a new user is that the docker route avoids host-specific toolchain setup, and the tools/ directory becomes optional rather than something you must install and maintain yourself. There is also a websim/ directory, and the What's New section describes it as a new web-based simulator for the NTS-1 mkii and the NTS-3. Its purpose is to develop, test and debug DSP code inside a web browser, to greatly speed up the development cycle. The README points to websim/README.md for how to use it. That is a meaningful addition for this domain. DSP development on an embedded target traditionally means build, flash, listen, repeat, with a long cycle and a hardware device in the loop. A browser simulator shortens the loop for at least the two newest platforms. Whether it fully models the target's audio path, and how closely, is not something the README states, so it is worth treating the simulator as a fast feedback loop rather than a substitute for hardware testing. The release history has one entry, 2.1.0 with the note WASM build support from 2025-08-04, which suggests the web simulator is built on WebAssembly. ## Support is community-run, and the SDK is provided as-is Two sentences in the README determine the support model. The SDK is provided as-is, no technical support will be provided by KORG. For community support, please visit the Discord. That is an honest position for a vendor SDK that ships the toolchain for a hobbyist and professional DSP programming on consumer synthesizers. Korg publishes the SDK, the templates and the toolchain, and the community carries the debugging. It also means the maintenance of the SDK and the maintenance of the community around it are different things, and the README gives you a way to tell them apart. The SDK version column in the compatibility table tells you which SDK generation your instrument expects, and it moves independently of how active the community is. The NTS-1 mkI is on v1.1.0, the mkII and NTS-3 are on v2.0.0, and microKORG2 is on v2.1.0, so a new instrument tends to arrive with a newer SDK generation. The last push was on 2026-09-14, and the latest listed release is 2.1.0 from 2025-08-04, which carries the WASM build support note. So the tree is being worked on, and the release tags are sparse. The licence is BSD-3-Clause, with the LICENSE file at the repository root, which is permissive and carries no copyleft obligation. For sharing your work, the README says to reach out to logue-sdk@korg.co.jp, and there is a Unit Index on the project's documentation site where ready to use oscillators and effects can be downloaded, along with instructions on the developer's website. A second index at logue-sdk.vercel.app is described as an easier to navigate unit index page, which is a small but real quality-of-life detail when you are looking through a catalogue of community units. ## Conclusion logue-sdk suits a DSP programmer who owns one of the supported Korg instruments and wants to write their own oscillator or effect in C against the vendor's SDK, since the platform templates remove the guesswork from the toolchain and the docker image removes the host OS problem. It is the wrong tool if you want a plugin for a desktop DAW, because the output is a firmware unit for a specific instrument, and it is the wrong choice for a hardware platform outside the listed set, since the unit format and the SDK version are tied to each product. Before you start, check the compatibility table for your instrument and its minimum firmware version, and read the Unit Index for existing units you can use as a starting point rather than writing an oscillator from scratch. ## FAQ ### Which Korg instruments does the logue-sdk support? The prologue, minilogue xd, Nu:Tekt NTS-1 digital kit, Nu:Tekt NTS-1 digital kit mkII, Nu:Tekt NTS-3 kaoss pad kit, microKORG2 and drumlogue, each with its own directory under platform/ holding files, templates and demo projects. ### What are the two unit formats in logue-sdk? The prologue, minilogue xd and NTS-1 mkI use a custom 32-bit LSB executable, ARM, EABI5 v1 (SYSV), static format on an ARM Cortex-M4, while the drumlogue, NTS-1 mkII, NTS-3 and microKORG2 use an ELF 32-bit LSB shared object, ARM, EABI5 v1 (SYSV), dynamic format on an ARM Cortex-A7 or Cortex-M7. ### Do I need a specific firmware version to install a logue-sdk unit? Yes. The compatibility table lists minimum firmware versions per product, for example v2.00 for the prologue and minilogue xd, v1.02 for the NTS-1 digital kit, and v1.0.0 for the drumlogue, NTS-1 mkII and NTS-3. ### Can I develop logue-sdk DSP code in a browser? Yes, for the NTS-1 mkii and the NTS-3. The websim directory holds a web-based simulator for developing, testing and debugging DSP code in a browser, with details in websim/README.md. ### Does Korg provide technical support for the logue-sdk? No. The README states the SDK is provided as-is and no technical support will be provided by KORG, and points to a Discord for community support. ## Sources - [korginc/logue-sdk on GitHub](https://github.com/korginc/logue-sdk) - [License: BSD-3-Clause](https://github.com/korginc/logue-sdk/blob/main/LICENSE) - [Project website](https://korginc.github.io/logue-sdk/) - [README](https://github.com/korginc/logue-sdk/blob/main/README.md) - [Releases](https://github.com/korginc/logue-sdk/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/korginc-logue-sdk