Thanks for taking an interest in SampleBuddy. It's a small, focused tool, so contributions that fit its scope — device profiles, format handling, bug fixes — are especially welcome.
npm install
npm run dev # launch in dev mode
Windows only, for now — see the README for why.
npm install compiles audify (RtAudio bindings, used for the Record mode's ASIO input capture) from source — .npmrc forces this so the build picks up ASIO support, which the package's prebuilt binaries don't include (Steinberg's SDK license means the maintainers can't ship ASIO-enabled binaries publicly; a local build picks up RtAudio's own vendored ASIO host-glue code automatically, no manual SDK download needed). This requires:
- CMake — either install it standalone, or use the copy bundled with Visual Studio Build Tools' "C++ CMake tools for Windows" component (typically at
...\Microsoft Visual Studio\2022\BuildTools\Common7\IDE\CommonExtensions\Microsoft\CMake\CMake\bin, which may need adding toPATHifcmake --versiondoesn't already resolve). - Visual Studio Build Tools, "Desktop development with C++" workload (provides the MSVC compiler).
No electron-rebuild/install-app-deps step is needed or run — audify targets N-API, which is ABI-stable across Node and Electron, so the module builds once against the host Node and loads fine in Electron as-is. (electron-builder install-app-deps used to be wired as a postinstall step here; it was removed because its native-module rebuild path assumes node-gyp/binding.gyp, and audify uses cmake-js/CMakeLists.txt instead — running it corrupts the working build rather than helping.)
native/vst-host/ is a standalone CMake/JUCE project, not part of the npm/electron-builder build (it's compiled separately and spawned as a child process — see src/main/audio/instrumentHost.ts). It backs the Instrument page: loading a VST3 (NI Kontakt is the one that matters, but any .vst3 works), showing its native editor window, driving it with MIDI from any connected input, and capturing its output as a sample. It needs the same CMake + Visual Studio Build Tools prerequisites as audify above, plus:
- Internet access on first configure —
cmake -S . -B buildFetchContents the JUCE framework (pinned tag, ~1-2GB) automatically; no manual JUCE install needed. JUCE also vendors the small ASIO SDK header subset it needs directly (Steinberg re-licensed those as GPLv3/MIT-dual in 2025) — no separate ASIO SDK download either.
Build with cmake -S . -B build -G "Visual Studio 17 2022" -A x64 then cmake --build build --config Release --target VstHost. Since a VST3 plugin's editor is a native window, Electron can't embed it directly — the host always shows the plugin's GUI as its own separate floating OS window, driven out-of-process via a simple stdin protocol (see Source/Main.cpp and scripts/spawn-test.mjs).
Licensing: native/vst-host/ links JUCE's ASIO support, which pulls in Steinberg's GPLv3-licensed ASIO headers — so this component is GPLv3 (native/vst-host/LICENSE), separate from the rest of SampleBuddy (MIT). It stays a genuinely separate process, talking to SampleBuddy only over stdin/stdout/exit-code and never linked into SampleBuddy's own binary — the same "separate program invoked as a subprocess" pattern already used for ffmpeg. See native/vst-host/README.md for the full rationale.
Packaging: npm run release bundles the built exe (and LICENSE) into the installer via build.extraResources in package.json, landing at resources/vst-host/ in the installed app (see src/main/audio/instrumentPaths.ts for how the main process resolves this at runtime vs. the dev-mode CMake build path). This means native/vst-host/ must already be built (per the steps above) before running npm run release — electron-builder will fail with a missing-file error otherwise, since unlike audify/ffmpeg there's no npm package to fall back on.
native/asio-control-panel/ is a small standalone CMake project (no JUCE, just the vendored Steinberg ASIO SDK host-loader files under Source/asio-sdk/), spawned as a one-shot child process by src/main/audio/capture.ts. ASIO has no standalone settings launcher — a driver's control panel (e.g. ASIO4ALL's) can only be shown by a host that loads the driver via COM and calls IASIO::controlPanel(), which audify doesn't expose — so this fills that gap. It needs the same CMake + Visual Studio Build Tools prerequisites as audify above; no internet access or FetchContent step needed since the SDK files are vendored directly in the repo.
Build with cmake -S . -B build -G "Visual Studio 17 2022" -A x64 then cmake --build build --config Release --target AsioControlPanel. See native/asio-control-panel/README.md for the licensing rationale (GPLv3, same reasoning as native/vst-host/) and usage details — notably that the driver's control panel window only renders once the host is pumping Windows messages, which is why the helper shows its own small "close when done" window and keeps a message loop running until that's closed, rather than exiting the moment controlPanel() returns.
Packaging: same as native/vst-host/ above — npm run release bundles the built exe via build.extraResources, landing at resources/asio-control-panel/. native/asio-control-panel/ must already be built before running npm run release.
- Fork the repo and create a branch off
master. - Make your changes. There's no linter or test suite configured yet, so validate by running the app (
npm run dev) and exercising the flow you touched — scan, convert, and (if relevant) drive upload. - Keep commits focused; a short, descriptive commit message is enough.
- Open a pull request describing what changed and why, and what you tested.
Most contributions will be new hardware sampler support. A device profile defines things like target format (bit depth, sample rate), transfer method (staging folder vs. USB drive), filename rules, and any drive-layout requirements (filesystem, folder structure). Look at the existing profiles for the SEQTRAK, Strike Multipad, and SP-404 MKII as the pattern to follow, and include the specific quirks your device needs (e.g. required folder names, filesystem/capacity limits) — that's the whole point of the tool.
If you don't have hardware to test against but know the spec, say so in the PR — it's still useful, just flag it so it gets extra scrutiny before merge.
Open an issue with:
- What device/profile you were using
- What you expected vs. what happened
- Sample files or filenames that triggered it, if relevant (redact anything sensitive)
By participating, you're expected to uphold the Code of Conduct. This is a hobby-scale project maintained in spare time — patience with response times is appreciated.