I think it’s time to do this. It would solve most of the vexing issues with a plugins repository.
TL;DR: This is built into Csound. It automates UPLOADING extensions, and it automates FINDING and INSTALLING extensions. Unlike Steven Yi’s proposal this does not automate BUILDING extensions, contributors are still responsible for that. But that could certainly be added later in the form of GitHub actions.
Here’s the current status of Csound versus its main alternatives regarding contributed extensions:
– Csound (open source), contributors maintain and distribute their own extensions. Partial exceptions: plugins and risset.
– Max/MSP (proprietary but most widely used), built-in package manager for contributed extensions.
– ChucK (open source), plugins repository for contributed extensions.
– Pure Data (open source), built-in package manager for contributed extensions.
– Purr-data (open source), many extensions are contributed to the main repository by pull request and maintained there.
– Supercollider (open source), plugins repository for contributed extensions, SuperCollider language extensions are in https://github.com/supercollider-quarks.
Csound gets a built-in package manager (cspm) for plugin opcodes, fgens, and extensions written in Csound languages (e.g. UDOs and instrument definitions).
This is a csound utility program/opcode. It is loosely modeled on the existing risset package manager, vcpkg, and deken. Simply using vcpkg would work, but would force contributors to jump through unnecessary hoops.
The package manager maintains contributions in a GitHub repository named csound-extensions, licensed LGPLv2.1.
The package manager commands are:
–contribute - upload a contribution to the contributor’s account in the csound-extensions repository. The contribution must consist of a directory in a standard format containing a package manifest and pre-built package contents. The contributor must have a GitHub account.
–list - list packages in the package repository.
–search - search in the package repository manifests.
–information - print the package manifest.
–install - install packages if the platform is supported.
–dependencies - list dependencies of packages.
–remove - remove packages.
A Csound extension package is a zip file with a .cse filename extension in the following structure based on Csound environment variables qualified where necessary by runtime architecture (specified as for vcpkg triplets, e.g. x64-windows, x64-osx, x64-linux).
SFDIR/ for soundfiles.
SSDIR/ for samples.
SADIR/ for analysis files.
INCDIR/ for .csd, orc., and include files.
OPCODE6DIR/triplet/ for loadable modules.
OPCODE6DIR64/triplet/ for loadable modules.
MFDIR/ for MIDI files.
deb/ for Debian packages.
exe/ for Windows installers.
dmg/ for MacOS installers.
apk/ for Android installers.
npm/ for NPM packages.
NODE/arch for binary Node.js and JW.js addons.
Extensions with third party dependencies are the main problem. Rather than solve this problem, either (a) the package contains an inner package that manages its own dependencies such as a vcpkg package or a Debian package, or (b) the manifest simply lists all third-party dependencies.
The manifest format is:
author: “author name”;
license: “standard license name”;
description: “What is this extension for?”;
repository: “where if anywhere is the source code repository?”;
tags: “comma-delimited list of searchable tags.”;
“triplet_1:” [list of dependencies];
“triplet_2”: [list of dependencies];
It is not necessary to list the contents of the package, that can be inferred from the archive.
As I mentioned, it would be possible to add automated builds for all supported platforms later, and this of course would also require creating Git submodules or source directories for each contribution, but what I have outlined should be doable pretty quickly.
The package manager uses the GitHub API to upload contributions from a contributor’s package directory as a pull request. And it uses the GitHub API to download packages, which it then installs according to the manifest.