Help

Publishing and exporting

List a plugin built with another framework

You don't need to rebuild a JUCE, iPlug2 or other plugin with Maru to give it a page, downloads and installs through Maru Desktop. What a listing gives you, what building with Maru adds, and how to list it.

No. If you already release a plugin with binaries on GitHub, you can list it on Maru as it is, even from a repository that holds only your release files. You add one file to the repository, and Maru gives the plugin a page under your name with your README, screenshots and a download for each platform. People with Maru Desktop on a Mac can install it from that page and receive your new releases as updates.

What a listing gives you

  • A page under your name, at /plugins/@your-login/your-plugin, with your README, screenshots, licence and the framework you used, such as "Built with JUCE".
  • Downloads from your GitHub releases, one row per file, with each file's platform, formats, size and the checksum GitHub recorded. Your files stay on GitHub; you never upload them to Maru.
  • Compatibility in your words. The systems, processors and DAWs you list are shown as declared by you, with your install notes.
  • Installs and updates through Maru Desktop, for a .zip of plug-in bundles on a Mac; on Windows and Linux, Desktop offers your download instead. Desktop tells the person the plugin comes from your GitHub release rather than from Maru, and installs it only when the file matches GitHub's checksum. It doesn't sign your build, so a Mac build you haven't notarized still shows macOS's own prompt the first time it opens.

People see that the plugin comes from you, not from Maru. Your page tells them the files are a community release that Maru hasn't reviewed or built, and that they download them at their own risk; Maru Desktop says the same before it installs anything. The Terms cover work other people publish on Maru. Clear install notes and the signing state you declare help people decide whether to install it.

A new release reaches your page and Desktop's updates when Maru reads your repository again. You can ask for that from your account, or let a GitHub Actions job ask on every release.

What building with Maru adds

A listing shows and delivers the plugin you already have. Building it with the Maru framework and publishing it on Maru adds what depends on Maru having the plugin itself:

ListingPlugin built with Maru
Page, README and screenshotsYesYes
DownloadsYour own release filesBuilds Maru makes and signs for each platform
Install and update in Maru Desktop.zip archives of plug-in bundles, on a MacYes
Play it in a web browserNoYes
Load it inside Maru Instrument, Maru FX and racksNoYes
Sell it through the marketplaceNoYes

You can list a plugin now and port it later; the listing doesn't need to change your build. For marketplace delivery of a plugin from another framework, which includes Maru's review of your files, read bring a plugin from another framework.

For example, a reverb you build with JUCE and release as a zip for Apple Silicon Macs, holding a VST3 and a standalone app, gets a page with that download, a note that macOS asks people to allow the unsigned build, and an Open in Maru Desktop button. Its file says the zip is for macOS 11 or later on arm64 and that you tested it in Ableton Live 12.

List your plugin

  1. Sign in to Maru and link the GitHub account that owns the repository at Connections.
  2. Add .maru/listing.json to the repository and commit it. Plugins built with other frameworks has a complete example and every field. The Maru CLI can draft the file with maru listing init and check it with maru listing check.
  3. Open Repository listings, choose Add a repository and enter the repository as owner/name. From a terminal, maru listing publish does the same.
  4. To publish each new release automatically, add the workflow in Publish a repository listing from CI.

If the listing doesn't appear

  • The file has problems. Repository listings shows each problem from Maru's last read, and maru listing check reports the same ones. Maru ignores a field it can't use and keeps the rest; a file that isn't valid JSON shows only what GitHub publishes about the repository.
  • Maru says your GitHub account isn't linked. Link it at Connections. It must be the account that owns the repository.
  • The repository belongs to a GitHub organization. Add your GitHub login to the file's credits with the role owner or maintainer, commit it, then add the repository again.
  • A new release isn't on the page. Choose Read again on Repository listings, or check the CI job's log. A prerelease is shown only when your file asks for every release.
  • Another account already manages the listing. Contact Maru with the repository and the GitHub account that owns it.

Go further: build it with Maru

When you're ready, you can port the plugin to the Maru framework and publish it on Maru. Your listing keeps working while you do. A plugin built with Maru gets what a listing can't offer:

  • A demo people can play on its page, in the browser, before they download anything.
  • A place in other people's setups. People can put it in a live rack or load it inside another module.
  • Remixes, if you release the source. People can make their own version, and the remix keeps your credit. The Maru Remix License explains what it allows.
  • Automated builds for each DAW format and operating system Maru supports, so you don't keep a build machine for each one. Pricing lists the plans with hosted builds.

If your plugin relies on something unusual, such as a custom machine-learning model, a video feed or other demanding processing, we work with you to find a way to build it with Maru. Contact Maru with what the plugin does and what it depends on.

Build an instrument or effect helps you choose a starting point. For the developer side, porting an existing plugin maps a JUCE plugin onto a Maru module, and Publishing covers the release.