Descriptions of all parameters of a plug-in should be mandatory. It’s quite annoying to be testing and frigging with a plug-in to see if it will do what you want, because parameters are not adequately explained, or even described in some cases. I think if Mod want’s to move forward it may need to take a step back and clean up stuff like that. Mod gear can do a lot, but it’s impossible to estimate how many people walked away from Mod gear because they found it wouldn’t do what they wanted it to do, when possibly it could.
For example, this plugin:
It has “slew”. That plug-in has attack and decay parameters, so slew isn’t the speed in which the compressor kicks in - it must be something else. Are users expected to reverse engineer plug-ins to better understand them?
I usually love my Mod Duo X for a month. Then I put it aside for 6 months because the time suck of building pedalboards is not insignificant. Workflow is key to all gear that I keep up with, the rest gets sold off.
Sorry for the rant, I spent an entire weekend on a pedalboard I thought I was going to finish in a few hours.
While I agree with the general point, documentation is always the hardest (and last) thing to get right in any (software) project.
Also because a lot of the plugins are not created by MOD this puts an additional burden to curate + enhance this information.
Having too much documentation can just as easily be off-putting (I don’t want to read all this text!), so it’s a fine balance of being both accurate, complete and still simple enough to comprehend.
100%.
This should have been the first thing after the reboot. Quality over quantity. Both in plugins and documentation. Throw out stuff or move to another section. Which I know is the hardest to do for on plugin alone (meaning AIDA-X) not to speak of the ones you’re just throwing onto the platform and not reviewing (the Modulay has the mix knob in the advanced view for example). Has been discussed a lot and I think this will only come with new plugins.
Plugin docs could be implemented as wiki pages. It would be much faster and easier than rebuilding third-party plugins adding that missing information. All that rebuilding, searching for authors, forcing them to write descriptions, removing working plugins for bad documentation from store seem really heavy and unprobable to really happen.
And that would be much easier to do community effort as a wiki.
Let’s say each plugin info page would include autogenerated link to a wiki page, named after plugin automatically.
On this page community could document what it can, parameters, use cases, as there would be much more space to write, formatting, images.
My assumption is that some form of testing has to happen for MOD to add a plug-in to the official repo. If a button is labelled “destroys your device” they probably don’t add it to the repo without figuring out what each parameter does. Whomever tests that a plug-ins works, is safe, and can be added, should also add the descriptions if there aren’t any, or ask the developer for that info.
This has been discussed numerous times over the years, and many people share your sentiment. Consider that if it were easy to do, more progress would have been made already. Many plugins of varying documentation quality were added in the earlier days when it wasn’t as much of a priority. Many of the initial plugins came from a circle of MOD and Linux audio developers and were already “vetted” by their collective quality and use. Even though I share your preference, requiring descriptions would exclude a lot of the popular and useful plugins.
Even for someone knowledgeable, there might be a wide gap between being able to figure out if a plugin will crash and being able to write accurate descriptions of each parameter’s function (that also reflects the author’s intent). Some plugins might operate differently depending on multiple parameter states, which might not be obvious to a casual reviewer. Since .lv2 is an open standard, many plugins have been “pulled in” from around the internet and the authors might not even be aware of MOD, or be interested in writing content for it. There’s also potential for conflict if third-party helpers with good intentions mislabel someone’s work or present it in a way that the author didn’t intend.
For perspective, I’ll say that my HR Pedalboard is probably worse in this regard since anything relating to descriptions or helpful labels would have to be found in online docs which aren’t always up-to-date.
This has nothing to do with LV2 being an open standard of course, but simply because these LV2 plugins happened to be open source and available to be ported over to the MOD platform.
But indeed adding descriptions without fully understanding how a plugin is “supposed” to work would have an adverse effect in disseminating inaccurate knowledge.
It’s in this sense better to be concise and accurate in the documentation, rather than elaborate and faulty.
My assumption is that if descriptions are open to the community, those who know will add the information, and if they are wrong, those who know can correct them. I’m not sure of the best process for that, but people are using plug-ins and figuring out what un-documented parameters are doing, so they should be able to update descriptions. Ultimately that is what the forums are doing - people ask, others reply - it’s a slower process which should be updated at the source.
