Skip to content

Workflow in Detail

Gorilla Engine projects combine a sonic core, a native application interface, product assets, and compiler configuration. The stages overlap in practice, but this sequence provides a reliable path from a new project to a distributable plugin.

Start by scaffolding a complete instrument or effect project. The generated project provides:

  • A Gorilla Engine project file (.ugep)
  • Instrument or effect source files
  • A React and TypeScript application
  • Asset directories
  • Build, installation, and deployment scripts

Follow the Quick Start to install and run the scaffolding tool.

Keep the generated project structure intact while learning the workflow. It establishes the paths and configuration shared by the application, Gorilla Editor, and Gorilla Compiler.

Use Gorilla Editor to build the sonic core of the instrument or effect. Depending on the product, this includes:

  • Importing and mapping samples
  • Creating keyboard ranges and velocity layers
  • Building synthesizer or effect signal flow
  • Configuring filters, envelopes, modulation, and effects
  • Routing audio between groups, buses, and outputs

At this stage, concentrate on how the product sounds and responds rather than on its final interface. Test the sound core in Gorilla Editor as it develops.

The Gorilla Editor overview introduces the tool, while the Gorilla Editor User Guide covers its operation in detail.

3. Model Product Behavior and Expose Parameters

Section titled “3. Model Product Behavior and Expose Parameters”

Use Gorilla Script to model how the instrument or effect behaves. Scripts can respond to note and controller events, select groups and samples, alter note properties, coordinate modules, generate notes, follow host tempo, and shape how the complete sonic core responds to a performance.

For example, a sampled piano might produce mechanical frame noises only when played at higher velocities. Gorilla Script decides when those samples trigger, how their level follows velocity and register, and how they fit alongside the primary piano samples. Similar logic can control release sounds, round robins, articulations, key switches, strumming, arpeggiation, or effect changes.

Gorilla Script also defines the parameters the application can control. An instrument with a filter may expose cutoff and resonance while keeping implementation-specific values private.

Choose the public parameter set deliberately:

  • Expose controls that are useful and musically meaningful.
  • Give parameters suitable ranges, defaults, and behavior.
  • Keep internal implementation details out of the product interface.
  • Use clear, stable names because the application binds to these parameters.

See the Gorilla Script overview and Gorilla Script reference.

The JavaScript interface controls the application layer of the plugin. This includes the visual interface, loading the exported sound core, interacting with its parameters, managing application and session state, handling presets, integrating licensing, and responding to the plugin host. There are two supported levels of abstraction.

Gorilla Engine React is the recommended approach for most products. It provides a declarative component model, hooks, reusable controls, and TypeScript support while rendering Gorilla Engine’s native UI components.

Use it for both straightforward parameter-bound interfaces and complex products with multiple views, shared state, instrument arrays, or host integration. Start with the Gorilla Engine React overview and the example closest to your product.

Use the Gorilla Engine JavaScript API directly when you need lower-level control or are building infrastructure beneath a component abstraction. Install and use @types/gorilla-engine for typed access to the API in TypeScript projects.

The low-level API provides native UI classes, instrument loading and parameter access, host information, session callbacks, dialogs, and other runtime facilities. Consult the Gorilla Engine JavaScript API for the available types and functions.

React and direct runtime calls can coexist. Although an application can be written entirely against the native runtime API, we recommend React for application structure and state management. It requires substantially less code and provides access to reusable Gorilla Engine packages for blob loading, sessions and presets, dialogs, licensing, controls, and logging.

See JavaScript Interface for a detailed comparison and the packages available for application development.

The interface determines how users understand and operate the product. During implementation:

  • Organize controls around user tasks rather than the internal signal graph.
  • Expose the smallest useful set of parameters instead of every available value.
  • Use clear labels, units, defaults, and visual hierarchy.
  • Plan resizing and macOS Retina assets from the beginning.
  • Validate workflows with musicians and producers who match the intended audience.

Keep images, fonts, animations, presets, and other runtime files in organized asset directories within the project.

Build and install the plugin early rather than waiting for the interface or sound design to be finished. The compiled product is where you can validate:

  • Parameter bindings and state restoration
  • Asset and instrument paths
  • Standalone and plugin behavior
  • DAW transport and host integration
  • Window sizing and display scaling
  • Plugin formats and installation paths

Use the project development command for rapid application changes after the initial build. Standalone-capable products can run their standalone application, while products that depend on DAW features should be deployed and tested in a host.

Rebuild when the .ugep configuration changes, including changes to outputs, exposed parameters, plugin formats, or other compiled product settings.

When the product behavior and interface are stable, use Gorilla Compiler to create release plugin formats and installers. Release preparation also includes:

  • Product metadata and versioning
  • Copy protection and licensing
  • Code signing and notarization
  • Installer signing
  • Installation and upgrade testing
  • Validation in every supported plugin host and operating system

See Licensing and Delivery for licensing, product delivery, and Product Hub guidance.

Product development remains iterative throughout these stages. Sound design may reveal a missing parameter, interface testing may improve a parameter range, and host testing may change product configuration. Keep the sound core, application, and compiled product under continuous test as they evolve together.