The plugins come with theirr own names and categories. They cannot (currently) be edited by an Ardour user. Please file a feature request at tracker.ardour.org. This doesn’t mean it will be implemented, but it will not be forgotten (which will happen with posts here)
Is the name and category stored in the plugin file in a way that it could be edited? Is all that information stored in the manifest.ttl file for an LV2 plugin such that modifying the manifest.ttl file would present a new name and category?
I wasn’t able to find the mechanism for LADSPA plugins in a few minutes of searching. The LV2 page has a description of bundles that pops up right away, but I haven’t gone through the details yet, so I’m jumping to conclusions a little bit.
Anyway, I guess what I’m getting at is IMHO the “right” way to do this would be with some kind of utility that modifies the plugin files or packages, and then just let Ardour discover the changes through the normal plugin discovery process.
Anyway, I guess what I'm getting at is IMHO the "right" way to do this would be with some kind of utility that modifies the plugin files or packages...
In terms of implementing the suggested feature, that would be exactly the wrong way to do it.
Why would that be the wrong way to implement the request? If you do it in Ardour, then the new names and categories are only visible in ardour. If you correct in the filesystem then every application will display the names and categories consistently.
Is the concern that updates will overwrite all the changes made? That would be a problem. Still don’t really like the idea of every app having to make provisions, you would end up with inconsistent descriptions for the plugins in e.g. Ardour vs. Qtractor.
Is the concern that updates will overwrite all the changes made..
Exactly.. Its already starting to get messy - alarm bells should be starting to ring...
...don't really like the idea of every app having to make provisions, you would end up with inconsistent descriptions for the plugins in e.g. Ardour vs. Qtractor...
And that's not a good thing, because each Application's plugin manager may choose to present the plugins in a way which means that one system is actually less relevant in some applications than others, so its acually better that you can customise whichever application you want, in the way that you want without affecting all the others. A change in one application should not affect the configuration of another, and that's effectively what you are suggesting.
Also, consider a use case where plugins are installed system-wide, on a multi-user system, any changes made by any user then become the “default” for any other user (you could install each plugin ‘per user’ but then each user would have to manage / update their plugins in order to be compatible with whatever the latest version of (many) different host applications are installed).
These things alone should be big signposts to the fact that this is the wrong way to do it. There is no simple or maybe “right” solution, because everyone will prefer a different method of sorting plugins, but there is definitely a wrong way to do it.
I think that a category like "unknown" or "plugin" isn't useful for anyone. So, imho, the correct way to handle such a problem would be to contact the developers/maintainers of the plugins...
Agreed, there is already a method for the plugin to provide useful information, which developers ought to use, the intrepid could of course also modify their .ttl files in the absence of any official fix - but (I for one) am not fond of .ttl files for plugin descriptors and I suspect other developers / maintainers feel the same so there may not be much enthusiasm to debug any resulting problems...