Official support for installing and updating community packages

[Seph_Reed]

A way for community creators to offer preset and sound packages to Bitwig users in the same way that official packages are offered. Bitwig currently has support for maintaining a curated list of first-party and chosen-third-party Content, and keeping Users up-to-date with that information by notifying them of changes, allowing install/uninstall/update, and managing all of the details of the synchronization. The same could be offered for community packages.

How this could be achieved:

1. Standardizing the Protocols relating to the Packages
2. Documenting the Standard and exposing it to the Community (publicly or with a few trusted parties)
3. Altering the Bitwig Packages feature to allow multiple Repositories

A potential prototype Protocol which would achieve these needs, and looks to handle what Bitwig already does (aside from Dependencies and compressed/uncompressed size), is shown below. This Manifest could be present at i.e. https://repo.bitwiggers.com/manifest.json, and a User could add that URL to their Repositories. Given this Response to that URL, Bitwig could show it as a Package and allow installing it.

{
  "packages": [
    {
      "name": "bitwigger's best",
      "authors": ["a", "b"],
      "externalUrl": "https://repo.bitwiggers.com/bitwiggers-best/about",
      "description": "a user-created package",
      "updatedAt": 12345,
      "iconUrl": "https://repo.bitwiggers.com/bitwiggers-best/icon.png",
      "items": [
        {
          "id": "saxophone",
          "sourceUrl": "https://repo.bitwiggers.com/bitwiggers-best/files/saxaphone.bwpreset",
          "destination": "presets/Polymer/saxaphone.bwpreset",
          "size": 123456,
          "sha256": "abcd"
        },
        {
          "id": "meow",
          "sourceUrl": "https://repo.bitwiggers.com/bitwiggers-best/files/meow.multisample",
          "destination": "multi-samples/meow.multisample",
          "size": 123456,
          "sha256": "abcd"
        }
      ]
    }
  ]
}

What problem(s) would this feature resolve?

Unless creators are working with Bitwig’s Team, there’s no ideal solution for delivering that Content to Users. Both the Provider and the Consumer must work out a custom/ad-hoc solution.

How does this feature fit in Bitwig as a product?

Bitwig already leverages this feature for their Official/Curated content. The community for Bitwig loves creating and sharing their content with others, so much so that we have multiple platforms outside of Bitwig to try to accomplish this goal. This request would connect a feature that is already working well on Bitwig with the increasing offer of community content that exists, for the benefit of Bitwig users.

Is there already an alternative way to achieve this on Bitwig?

Within Bitwig, no. Everything would be created/managed somewhere else, and there’s a lot of potential there - it’s just that none of it is easy or standard.

For example, Bitwiggers is manual-in and manual-out, or a Compressed Archive could be created and uploaded somewhere else. Both are one-off or ad-hoc situations.

It is also possible to clone a git repository with presets in your Presets folder, but this is a workflow totally external to Bitwig, and rather technical or unfamiliar for music producers in general.

Could it be implemented using Bitwig components or APIs, without Bitwig team’s support?

Not within Bitwig, no, and not using anything that Bitwig provides (outside of a concept of the folder-structure.

Could it be provided by a VST or something else reasonably integrated with Bitwig?

The community could build similar concepts outside of Bitwig. Polarity has tried making his own repositories and Windows programs to keep users up-to-date with his own Presets. A similar solution for Bitwiggers was proposed but not received with high demand from the Users.

Are there other products that offer this feature?

Native Instruments offers infrastructure for Community User Libraries and also the user features to install these packages and jeep them up to date. In this case, it’s a centralized repository with NI’s terms and conditions.

Relevant links (optional)

[somethingtohide]

This is an excellent idea, and I’d love to explore it. I also am not familiar with the protocols, but it could be fairly-easy metadata. Off the bat, there’s a few complexities/differences to sort out:

• As far as I’ve found, there’s no IDentifiers present in Bitwig’s files; I need IDs for each file, so I chose to essentially hash the files themselves to create that ID. There’s an important side-effect to this approach: making any change will create a new unique ID. This makes it hard to relate data, or in other words “version” the files.
• Aside from per-file updates, there must be a way to reconcile overall updates to the package. If this process is handled locally by Bitwig, that would be the ideal case and this could be an easy task. If not, so that it would rely on the package itself notifying what has changed, then this would become too difficult to do in bulk, but perhaps still feasible enough for a few “curators” to manage.
• How exactly would the Packages be formed? There’s already two options in this thread (not necessarily mutually exclusive)
  • A specific user links the related data together as a package.
  • Bitwiggers produces a package based on a query.

In any case, this addresses many features that I had hoped to explore, and in a way that’s preferable to all other existing suggested solutions.

[Seph_Reed]

For IDs, I feel like file.name + file.creator should be unique enough. OFC having one update on you could be odd… but so would not having it update. UX question there.

I think that if the manifest.json was something like (lazy json):

packageName: "bitwiggers best",
subPackages: [
  {
    name: "soemthingtohide's faves",
    items: [
      { path: "http://site.com/bitwiggers-best/somethingtohides-faves/kick.wav", updatedAt: 12345 },
      { path: "http://site.com/bitwiggers-best/somethingtohides-faves/hat.wav", updatedAt: 12345 },
      { path: "http://site.com/bitwiggers-best/somethingtohides-faves/saxaphone.bwpreset", updatedAt: 12345 },
      { path: "http://site.com/bitwiggers-best/somethingtohides-faves/meow.multisample", updatedAt: 12345 }
    ]
  }
]

Given the above, it would be fairly simple for Bitwig to compare an old manifest.json with a new one and see if anything was missing or updated. I’m still not sure about the update userflow though. They could just ignore it, and that’d still be cool.

And for how the package is formed, I think it must be broken up into multiple chunks, otherwise you couldn’t possibly “pick and choose” anything. In regards to grainularity, I personally prefer the “list every single file” approach over compressing each sub-package, but that’s just because it’s extra KISS. However Bitwig already does it is the way to go though.