Home | ER-101 | ER-102 | ER-301 | Wiki | Contact

Package management, distribution, organization - V0.6

Firmware 0.6 brought forth the concept of “packages” along with a host of sharing and low level preset building powers. Along with those powers, questions arise how to organize the packages, where to collect them, keep them updated, versioning, categorizing and naming conventions possibly? Let’s collect our ideas. (I will try to merge a few topics if I have the power to do so)

3 Likes

It’s a good topic. At the moment, there aren’t so many custom creations out there in the wild that it’s unmanageable. But I could see that changing given the opening up of the lower layer, and also that UI layer creations now end up in the main insert menu too. Could proliferate a lot of units and presets into it.

Personally if I’m looking for a filter, I’d usually prefer to see all of my options in one place, under a category called Filtering. But I could also see it being useful to filter by package name, if I know the name of a package where the filter exists. And it might also be useful to be able to see all the units that are part of lojiks isolated, for example.

There are also “keywords” in the toc.lua file for packaged mods. I’m not sure what they’re used for or how they are intended to be different from categories.

Edit: couple more thoughts while they’re fresh in my mind

I think a nice enhancement to the package manager system might be the ability to drill down and install/uninstall individual units. Accents is getting up toward 30 units. You might like 20 of them, but think you won’t use the rest, so they are effectively just cluttering up your insert menu.

As someone who creates units, I’ve been somewhat struggling with whether to split a large package that contains a lot of units into smaller packages that are focused on a particular function. In a way though I think it’s nice to have one file to download and install vs. having to download a bunch of stuff piecemeal. There’s also the conundrum of dependencies. For example there might be a unit in Accents that you don’t think you’d use directly, but someone might make a unit preset that you like that uses that unit.

Better start now, indeed. Regarding the categories: what you said definitely makes sense, but personally, I would like to see the categories spread out between packages something along these lines:

- Filters
| - LPF
| - HPF
| - etc.
- Accents: Filters
| - BPF
| - etc.

Just because I found I spend too much time looking for units if the category gets crowded. But we are just two users and already there are two different propositions :slight_smile: I guess we will have to talk about this!

I’m just reading your edit… I agree about the “drilling” capability, that would be the smoothest for both parties, dev and user!

In lieu of a formalized system, can we lean on the wiki for this? I’m imagining a whole index devoted to navigating the current set of plugins organized by category.

Something like ER-301/User Contributed Presets - O|D Wiki but focused on 0.6+ only.

EDIT: whoops, just realized this might not be about package discovery (i.e. on the web) but instead about the package interface in the 301. Feel free to spin off or otherwise ignore this comment!

Finding the best way to make packages available to everyone is one of the main goals of the thread! :slight_smile: The Wiki is fine for general content that doesn’t change much but it has hardly proven to be efficient in reflecting the latest and greatest efforts of the community. We were talking about something like a GitHub page in another thread So v6 - dare I ask? :) - #40 by Bparticle but the conversation was abandoned. The idea is to continue it here.

It’s possible we could build a github page in a repo to list things in a manageable / searchable way. Creators would have to make a PR to update the static list though which can be a barrier to entry.

Would be nice to separate libs / units / presets in search and list deps, for most packages the assets/toc.lua provides all the information you need to index things.

1 Like

It’s too bad ER-301 doesn’t have network access. Norns uses a manifest that is essentially a list of GitHub URLs. Menus for installing scripts are built from that manifest.

I can imagine a web or desktop app that does something similar, looks at the state of a front card plugged into a computer, and provides a UI for downloading or updating (or deleting) packages from the card.

I think there’s a couple of things to resolve: discovery – how do people find packages to use (assuming there will be a large number); management – how do people install / uninstall / upgrade, etc. On top of that, I think there is as of yet an assumption that the packages will be free and/or open source, neither of which I am assuming at this point.

I’m still holding out hope that some DSP players will enter the scene at some point and they may not want to give away their secrets.

1 Like

I think a GitHub page is still the best option. I’m wondering if this could be a page onb the Orthogonal Devices account? I’m not sure if Brian would be up for that. This would come pretty close to having an “official” list of community built units and presets. The barrier is there, but will always be there I think, if we are talking about a proper way of keeping things organized.

Is there going to be some kind of distribution hub or package manager? Having to trawl through the forums to find good stuff and updates is kind of a pain sometime. Especially if we start having a dependency tree that has more things on it then just accents!

I don’t have plans for such. The ER-301 is not a networked device so…maybe the community will organize something?

Oh, come on! You don’t want to spend all of your time reinventing the package management wheel for the ten thousandth time?! :laughing:

Honestly just a communal github repo with the packages and markdown docs in it, a file you put on the sd card that has the names and versions you want and a simple script/program to fetch/update the packages from the repo would probably do the job. I’m sure some of us could put something together.

6 Likes

Thank you! :wink:

2 Likes

I’d love to help with this, though I caution that I’m pretty time-poor at the moment. I’ll do what I can though.

Never looked into it, but there is a solution built into GitHub apparently. Free for public repos so that’s covered. Anyone experience with GitHub packages?

1 Like

My .05:

  1. As automated as possible
  2. Each contributor should have responsibility to maintain their stuff
  3. If possible contributor can only write their own stuff
  4. There should be some agreed upon practice up front on how to handle abandoned stuff (transferred ownership)

My vote goes to GitHub!

6 Likes

There also needs to be a simple way to declare which firmware version a package is compatible with, with super clear handling / instructions for general users, to avoid the “does this work with vX” questions that have already popped up a bit.

And perhaps some path towards some kind of approved package status that can allow good packages to be added into a core library. Or something. Without making it burdensome.

1 Like

mine as well, esp. for open source ‘packages’ / units. forks are really neat.

1 Like

Thinking about this, I don’t think package manager is the way to go as IMO it’s overkill and requires users to download custom software that needs to run on any OS.

I think a central repo of references to github repos similar to an “awesome list” (example) is a good mechanism. Contributors could then open PRs to submit links to middlewares and presets. The repo could also host some guidelines on what is best to include in your own repo like download instructions, perhaps naming conventions for units (lower case params, title case units - maybe that’s just wishful thinking). We could go beyond the awesome list approach and make a github pages branch that hosts a searchable UI that can pull in each project’s readme and clone url to make it a one stop shop, but honestly the awesome list format seems like enough to me.

I think Monome has handled this really well with their Maiden online tool. Even though 301 don’t have WiFi for transfer I’m sure the transfer can be solved in some other way.

4 Likes