EffeTune Build and Packaging Guide
This document provides instructions for setting up the development environment, validating the web app, and building the EffeTune desktop application using Electron.
Prerequisites
Before you begin, ensure you have the following installed on your system:
- Node.js (v22.12 or later)
- npm (v10 or later)
- Git (for cloning the repository)
Development Environment Setup
1. Clone the Repository
git clone https://github.com/your-username/effetune.git
cd effetune
2. Install Dependencies
Install all required dependencies for the project:
npm install
This will install:
- Electron (as specified in
package.json) - Electron Builder
- Other dependencies required by the application
3. Run Quality Checks
Run the default validation before handing code changes back:
npm run verify
This runs:
npm run lint: ESLint checks for JavaScript syntax and high-confidence correctness hazards across Electron, renderer, plugin, feature, tool, and test codenpm test: Node.js tests with the repository’s coverage thresholds and test hygiene checks
Before lint and tests, npm run verify rebuilds the browser vendor assets and performs a
non-writing freshness check of the committed PWA precache. It does not regenerate a stale
sw-precache.js; if that check fails, run npm run assets:web and then rerun
npm run verify.
For narrower verification, use:
npm run lint
npm test
Changes to the power-saving policy, audio-pipeline lifetime, input ownership, or resume behavior must also pass the browser smoke test:
npx playwright install chromium
npm run test:power-browser
The Playwright install command is needed only when Chromium is not already available. The smoke-test runner starts and stops its own temporary loopback server; do not start a separate development server for this command.
For release-candidate device coverage and repeatable battery/power observations, complete the Web/PWA power-saving measurement record.
4. Build and Test the DSP Core
The committed WebAssembly DSP artifacts let JavaScript-only contributors run the app
without Emscripten. Changes under dsp/, plugins/dsp/, or a plugin’s DSP parameter
schema require the pinned toolchain recorded in dsp/EMSDK_VERSION (currently 6.0.2),
CMake 3.24 or newer, Ninja, and a C++20 compiler.
npm run gen:dsp
npm run test:dsp
npm run build:dsp
npm run test:dsp:parity
gen:dspvalidates everyparams.jsonand updates the generated C++ and JavaScript parameter layouts.test:dspbuilds the native core, allocation guard, and parity runner, then runs CTest.build:dspverifies the active Emscripten version and rebuilds the committed baseline and SIMD modules plus deterministic metadata underplugins/dsp/.test:dsp:paritychecks both shipped modules against the committed JavaScript goldens.
Set EMSDK to the activated SDK root on Windows. Use npm run build:dsp -- --check for
a write-free freshness check. Kernel preparation and instance creation run between audio quanta and may
grow WASM memory; processing itself must never allocate, lock, perform I/O, or grow
memory. See dsp/README.md for the ABI and kernel workflow.
For a browser runtime check, open the served app, start the audio graph with a user
gesture, and confirm the console stays free of [dsp-wasm] warnings. Repeat once with
?dsp=off and confirm that the JavaScript compatibility path starts without any
[dsp-wasm] messages. Browsers that do not acknowledge a cloned compiled module are
retried automatically with the retained WASM bytes.
5. Run in Development Mode
To start the application in development mode:
npm start
To debug the web version in a browser with no-cache dynamic loading for plugins:
npm run dev
Then open:
http://localhost:8000/effetune.htmlfor the web apphttp://localhost:8000/for the local documentation site homehttp://localhost:8000/docs/i18n/ja/for a localized documentation pagehttp://localhost:8000/dev/effetune_test.htmlfor the development test page
The development server renders the documentation Markdown locally with the site layout, so the public site structure can be checked without running Jekyll separately.
Building the Application
EffeTune can be built as a portable application or as an installer. The build process is configured in the package.json file under the build section.
Build Configuration
The build configuration in package.json includes:
- appId:
com.frieve.effetune - productName:
EffeTune - Output directory:
dist - File associations:
.effetune_presetfiles - Build targets:
- Windows: NSIS installer and portable executable
- macOS: DMG (x64 and arm64 architectures)
- Linux: AppImage
Build Commands
To build the application, use the following npm commands:
- Build all versions:
npm run build - Build portable app only:
npm run build:portable - Build installer only:
npm run build:installer - Build macOS application:
npm run build:mac - Build macOS application (ARM64 only):
npm run build:mac:arm64 - Build macOS application (x64 only):
npm run build:mac:x64 - Build Linux application:
npm run build:linux - Clean the build directory:
npm run clean
The Electron build scripts and GitHub Pages workflow run npm run assets:web automatically before packaging or deployment. This regenerates the browser metadata parser bundle, its third-party notice file, and sw-precache.js. If you add or remove web assets outside those flows, run npm run assets:web before committing.
Web and PWA Assets
The web app uses manifest.json, sw.js, and generated sw-precache.js for installable/offline app-shell support. Service Worker registration is web-only and is skipped in Electron.
Before release, verify that the web app loads normally, can be installed where supported, and still opens after going offline once the app shell has been cached.
Build Output
After a successful build, you’ll find the following in the dist directory:
- Windows Portable application:
EffeTune-x.xx.x-Portable.exe(where x.xx.x is the version number) - Windows Installer:
EffeTune-x.xx.x-Setup.exe(NSIS installer) - macOS application:
EffeTune-x.xx.x-x64.dmg(Intel Mac)EffeTune-x.xx.x-arm64.dmg(Apple Silicon Mac)
- Linux application:
EffeTune-x.xx.x.AppImage - Other build artifacts: Various files created during the build process
The file naming convention has been configured in the package.json file to clearly distinguish between the portable application and the installer.
Application Structure
The EffeTune Electron application consists of several key components:
Main Process (main.js)
The main process is responsible for:
- Creating and managing the application window
- Setting up the application menu
- Handling IPC (Inter-Process Communication) with the renderer process
- Managing file system operations
- Handling audio device enumeration
Preload Script (preload.js)
The preload script securely exposes Electron APIs to the renderer process through the contextBridge:
- File system operations
- Documentation rendering
- Audio device operations
- IPC event listeners
Electron Integration (js/electron-integration.js)
This module integrates the web application with Electron-specific features:
- Detecting the Electron environment
- Handling file import/export
- Managing audio preferences
- Processing audio files
- Displaying dialogs
Customizing the Build
Application Icon
To change the application icon:
- Replace
images/favicon.ico(Windows) andimages/icon.png(macOS/Linux) with your custom icons - Ensure the icons are referenced correctly in the
buildsection ofpackage.json
Application Metadata
To modify application metadata:
- Update the relevant fields in
package.json:nameversiondescriptionauthorlicense
Installer Options
To customize the installer behavior:
- Modify the
nsissection in thebuildconfiguration inpackage.json
Bundled Files
The build.files array in package.json is an explicit allowlist of top-level directories and files to bundle into the application. This keeps repo-only assets (Jekyll site files, dev scripts, docs metadata, untracked work-in-progress files outside the allowlisted directories, etc.) out of the installer.
When adding a new top-level directory or root file that must ship with the app, add a matching entry to build.files. Otherwise the build will silently omit it.
Root web assets such as effetune-mobile.css, sw.js, sw-precache.js, manifest.json, icons, screenshots, and vendor scripts must be included when they are required at runtime.
Troubleshooting
Common Build Issues
- Missing dependencies:
- Ensure all dependencies are installed with
npm install - Check for any peer dependency warnings
- Ensure all dependencies are installed with
- Build fails with code signing errors:
- Set
forceCodeSigningtofalsein the build configuration - Or provide valid code signing certificates
- Set
- Electron download fails:
- Check your internet connection
- The build configuration includes
strictSSL: falseto help with some network issues
- Antivirus blocking the build:
- Temporarily disable antivirus software
- Add exceptions for the project directory
Runtime Issues
- Audio device access problems:
- Ensure proper permissions are granted to the application
- Check the audio device configuration in the application settings
- File association issues:
- Reinstall the application using the installer
- Manually associate
.effetune_presetfiles with the application
Distribution
After building the application:
- Testing:
- Test the application thoroughly on the target platforms
- Verify all features work as expected
- Distribution:
- Upload the installer and/or portable application to your distribution platform
- Update the download links in your documentation
- Updates:
- Increment the version number in
package.jsonfor new releases - Consider implementing an auto-update mechanism for future versions
- Increment the version number in