Extend YAML file specification

[sadko4u]

Hello!

Recently I've received the request to add my plugin suite to your registry:
lsp-plugins/lsp-plugins#538

I found that my current type of distribution doesn't fully match the spec:

• LSP plugins are provided as a set of different plugins bundled into a single package, and there is no type 'bundle' for distribution, only 'instrument', 'generator', 'sampler', 'tool' and 'effect'. There is a need to add support of such packages. Same is true about Calf, Invada and other plugin distributions which include multiple plugins in a single package.
• There is no specification of RISC-V (32-bit, 64-bit and possible 128-bit) in file architectures. I also think that it would be nice to add other modern architectures like ppc64el, loongarch, etc.
• There is no possibility to provide an archive with source code in the file list. For this case the architecture should be set to 'noarch' or something like this and 'contains' should be something like 'source'.
• LSP Plugins provide builds for FreeBSD. There is no FreeBSD operating system support in the list of operating systems.

[sadko4u]

I also think that it could be a good option to specify the list of plugins provided by the bundle. Ideally there should be list of following items:

• Plugin description (string) - Compressor.
• Version (version) - 1.1.0
• Type of plugin (enum) - effect.
• Optional list of plugin variations (string):
  • Compressor Mono;
  • Compressor Stereo;
  • Compressor Mid/Side;
  • Compressor Left/Right;
  • Sidechain Compressor Mono;
  • Sidechain Compressor Stereo;
  • Sidechain Compressor Mid/Side;
  • Sidechain Compressor Left/Right.

[kmturley]

Hello,
Thanks for your detailed thoughts. This is an open-standard and there are definitely things that could be improved using feedback like yours.

• LSP plugins are provided as a set of different plugins bundled into a single package, and there is no type 'bundle' for distribution, only 'instrument', 'generator', 'sampler', 'tool' and 'effect'. There is a need to add support of such packages. Same is true about Calf, Invada and other plugin distributions which include multiple plugins in a single package.

The current specification already allows for some flexibility:

Bundle/collections within a single package:

• https://studiorack.github.io/studiorack-site/plugins/airwindows/airwindows
• https://studiorack.github.io/studiorack-site/plugins/distrho/dpf-plugins
• https://studiorack.github.io/studiorack-site/plugins/michaelwillis/dragonfly-reverb
• https://studiorack.github.io/studiorack-site/plugins/audioplugins/iempluginsuite

Org/groups with separate packages:

• https://studiorack.github.io/studiorack-site/plugins/sfzinstruments
• https://studiorack.github.io/studiorack-site/plugins/tiagolr

Dynamic groups based on tags with separate packages:
https://studiorack.github.io/studiorack-site/plugins?search=&category=drums

Looking at your plugin collection: https://lsp-plug.in/?page=plugins it contains multiple "types" instruments, effects, tools. But our spec only allows one to be defined:
https://github.com/open-audio-stack/open-audio-stack-registry/blob/main/specification.md#plugin-types

We made the choice in the spec to have a primary type per package, as the majority of instruments are distributed separately from effects. It would be a large spec change to allow for multiple types. Adding a type "bundle", wouldn't tell us what is inside, so I am not sure if that would be a better solution. For a collection, could you use the primary most common type e.g. effect. The type categorizes one way to find plugins, but they can be discovered via tags and description too, so not sure it would hide the plugin from potential users?

• There is no specification of RISC-V (32-bit, 64-bit and possible 128-bit) in file architectures. I also think that it would be nice to add other modern architectures like ppc64el, loongarch, etc.

We debated adding other architectures, but didn't find many plugins compiled for other than ARM/x86 32/64bit.
https://github.com/open-audio-stack/open-audio-stack-registry/blob/main/specification.md#architectures

Looking at those suggestions, do you see use-cases for audio packages in these?

• RISC-V embedded systems, IoT devices, and even some server applications
• PowerPC 64-bit Little Endian high-performance computing and servers
• LoongArch primarily used in China

I'm open to adding them to the specification if they provide a benefit. I have been supporting architectures based on NodeJS list: 'arm', 'arm64', 'ia32', 'loong64', 'mips', 'mipsel', 'ppc64', 'riscv64', 's390x', and 'x64' and renaming slightly for consistency. arm -> arm32 and ia32 -> x32
https://nodejs.org/api/os.html#osarch

• There is no possibility to provide an archive with source code in the file list. For this case the architecture should be set to 'noarch' or something like this and 'contains' should be something like 'source'.

This is an interesting idea. To date I assumed that musicians would only want precompiled binaries. What would the use-cases for source code? to make modifications and build their own version? or build for another system? I wonder if linking them to GitHub is sufficient, as it would require technical skills and a README guide?

• LSP Plugins provide builds for FreeBSD. There is no FreeBSD operating system support in the list of operating systems.

We currently have Linux, Mac and Windows in the specification as the most common operating systems:
https://github.com/open-audio-stack/open-audio-stack-registry/blob/main/specification.md#systems

This is based on this list:
'Linux' on Linux, 'Darwin' on macOS, and 'Windows_NT'
and underneath uses uname for Linux distros
Linux, Darwin, FreeBSD, OpenBSD, NetBSD, SunOS, AIX, HP-UX, CYGWIN_NT-X.X
https://nodejs.org/api/os.html#ostype

Again we didn't encounter any other plugins built for other operating systems, but we could absolutely add them if you think they are valuable?

[kmturley]

I also think that it could be a good option to specify the list of plugins provided by the bundle. Ideally there should be list of following items:

• Plugin description (string) - Compressor.

• Version (version) - 1.1.0

• Type of plugin (enum) - effect.

• Optional list of plugin variations (string):

  • Compressor Mono;
  • Compressor Stereo;
  • Compressor Mid/Side;
  • Compressor Left/Right;
  • Sidechain Compressor Mono;
  • Sidechain Compressor Stereo;
  • Sidechain Compressor Mid/Side;
  • Sidechain Compressor Left/Right.

Yes we have been discussing this in a separate issue. installer and archive files can contain multiple files, and there is no way to know what the files are that will be installed. Also there is no mapping for where to extract files from an archive, if they need to go into different places.

I think it's worth support optional additional file metadata under a the contains attribute such as

{
  "systems": [
    {
      "type": "linux"
    }
  ],
  "architectures": [
    "x64"
  ],
  "contains": [
    { type: "elf", "path": "standalone/plugin", "extract": "$pluginDir/standalone" }
    { type: "clap", "path": "CLAP/plugin.clap", "extract": "$pluginDir/CLAP" },
    { type: "vst3", "path": "VST3/plugin.vst3", "extract": "$pluginDir/VST3" }
  ],
  "type": "archive",
  "size": 11138914,
  "sha256": "a9a9a9b42e111bd41ee24157368ca2499cace806c505f7f8ccd9aeec03f251b7",
  "url": "https://github.com/surge-synthesizer/monique-monosynth/releases/download/Nightly/MoniqueMonosynth-2024-08-07-df7d339-Linux.zip"
}

https://open-audio-stack.github.io/open-audio-stack-registry/plugins/surge-synthesizer/monique-monosynth/

But would need to think more about this before implementing.

[sadko4u]

Yes we have been discussing this in a separate issue. installer and archive files can contain multiple files, and there is no way to know what the files are that will be installed. Also there is no mapping for where to extract files from an archive, if they need to go into different places.

No, it's not about it. Actually I have a single lsp-plugins-lv2.so file which internally contains set of plugins. The idea is that list is a good way to tell the indexer about the original set of plugins provided by a single file. For example, if indexer sees the type as bundle, it looks into sub-list called something like provides and gets a list of plugins and their types as I described previously. So if you search for 'Compressor' plugin, you will see it because it is listed in the provides list. Otherwise you won't see the 'LSP Plugins' in the search list because the indexer doesn't know anything about LSP Plugins provide.

This is an interesting idea. To date I assumed that musicians would only want precompiled binaries. What would the use-cases for source code?

I think it may be useful for packagers or enthusiasts who want to build plugins from scratch. According to my case, I don't plan to distribute binaries for MacOS and Windows for free even if I support these platforms. Otherwise, the GPL and LGPL licenses require to provide source code for the product by demand. So anyone who don't want to purchase binary builds in our store can build plugins by themselves.

Looking at those suggestions, do you see use-cases for audio packages in these?

I know that LSP plugins are already packaged for these architectures in some Linux distributions (Debian is a primary example). RISC-V is rapidly evolving microarchitecture as there are many vendors that do not want to pay royalties to ARM for their chip design. Loongarch is also an evolving national architecture in China, it also may become popular.

The current specification already allows for some flexibility:
Dynamic groups based on tags with separate packages:

Tagging bundles is a good idea but tags don't allow to search plugin by name. The idea with 'provides' looks more common for this case.

Again we didn't encounter any other plugins built for other operating systems, but we could absolutely add them if you think they are valuable?

I suppose it is valuable, too. For example, Haiku is also a modern operating system which has a community that ports FOSS audio solutions to this platform. Some of LSP Plugins are essential part of EasyEffects now and they are demanded everywhere where EasyEffects are provided, too.

[sadko4u]

Here is an example of metadata that LSP Plugins generate when building.

plugins.json

[RustoMCSpit]

Yes we have been discussing this in a separate issue. installer and archive files can contain multiple files, and there is no way to know what the files are that will be installed. Also there is no mapping for where to extract files from an archive, if they need to go into different places.

Relevant issue #138

Tagging bundles is a good idea but tags don't allow to search plugin by name. The idea with 'provides' looks more common for this case.

We didn't account for every possibility of distribution, including this niche one. I do agree though this has been an oversight in the standard more generally. If you want to discuss this more, you'd be better going to #138

[RustoMCSpit]

I think it may be useful for packagers or enthusiasts who want to build plugins from scratch. According to my case, I don't plan to distribute binaries for MacOS and Windows for free even if I support these platforms. Otherwise, the GPL and LGPL licenses require to provide source code for the product by demand. So anyone who don't want to purchase binary builds in our store can build plugins by themselves.

Same problem here, some FOSS plugin devs do not provide binaries intentionally. We have to decide whether or not to support that, I think we shouldn't.
greyboxaudio/SG-323#24 (comment)

[RustoMCSpit]

Same problem here, some FOSS plugin devs do not provide binaries intentionally. We have to decide whether or not to support that, I think we shouldn't.

Actually, I'm setting up a repo full of plugin UI art assets, hence #149, the ability to tie source codes might be useful. This would be feature creep but it is convenient for that