Prettier URLs for plugins

Contribute General Questions & Feedback
#1

The URLs for plugins are long and ugly, e.g.

It would be much nicer if these URLs were in this format:

1 Like
Could be easier to find list of plugins
#2

that would make the final URL a double-url, like https://pedalboards.moddevices.com/plugins/https://plugins.moddevices.com/MDA-DubDelay.
This is not allowed… encoding the 2nd url would not make it that much prettier in the end.
Personally I don’t see any usability gains with this proposed change…

#3

Why? Either I’m missing some information (likely) or you misunderstood my proposal (less likely). I am proposing that the final URL would be

This would presumably involve two steps:

  1. introducing an extra field in the plugin database model for a unique human-friendly string for each plugin which can be embedded in a URL, e.g. MDA-DubDelay (maybe this field even already exists?)
  2. setting up the new subdomain plugins.moddevices.com

I’m definitely not proposing anything that would result in double-URLs. I’m just proposing the standard web technique of providing human-friendly permalinks to plugins. On platforms such as Wordpress these are referred to as “slugs”.

1 Like
#4

Fully agree with @aspiers – it might appear to be only cosmetics but having permanent and stable URLS/links is useful for documentation and archiving purposes, too.

#5

What you’re asking is not possible in the LV2 context.
Plugins have URIs as identifiers. If you propose using a small string as another unique identifier, then someone will have to become the authority to manage such list.

For example the case of MDA plugins, there are quite some variants out there. There’s the original port by drobilla, the MOD fork and some individual projects that developed specific plugins (like extending the Piano’s features).
When mapping the mda-piano to a URI, someone would have to dictate which final plugin is used.

What is feasible to do, is to have this mapping within the MOD ecosystem only.
This would involve some changes to our infrastructure right now, extra work for which I don’t personally see any gains.
(also for archiving purposes, the mapping list would have to be kept forever.)

Still, we will consider this again at some later point.

1 Like
#6

That makes sense; thanks a lot for the explanation and the consideration of this for the future! I appreciate that there are much more urgent things which need doing first though :slight_smile: