easyeffects
easyeffects copied to clipboard
wwmm
What to do with documentation?
With the new multiband compressor and limiter, there's a need to update the documentation. Besides, Markus guide for laptop should be adapted to the new plugins and there are other things to fix for other plugins.
Anyway new updates should be also translated. Honestly, I'd like to update the main English one, but if I think I have also to translate the Italian one, I'm not motivated to do it.
Unfortunately the documentation is important, but also boring to deal with and the most boring part is the translation. Then, let's be honest, most of the available translations are partially completed and will never be completed. Therefore I suggest to remove translations and leave only the English one, kept 100% updated.
It's not only because I'm not motivated to translate it, but primarily because documentation is too important for this application and we should put all the effort in keeping it updated rather than working on translations which will never be 100% updated and partially translated ones are a big downside because they are more confusing to the user. Obviously this argument does not apply to user interface translation.
Considering that plugin official documentations are only in English and in our documentation we refer to them, I recommend to keep the documentation really updated removing all the translations, so we have a unique place, same for all locales, easier for us to maintain and without misleading information.
What do you think?
Anyway new updates should be also translated. Honestly, I'd like to update the main English one, but if I think I have also to translate the Italian one, I'm not motivated to do it.
I have the same feeling about the pt_BR translations. I stopped doing them a long time ago. Even for the window labels...
Unfortunately the documentation is important, but also boring to deal with and the most boring part is the translation.
I agree. It is really boring. Any free time I have available for this project always goes to the code.
What do you think?
It is a hard decision to make. But I think we could remove the translations for the documentation and see how people react. Considering how rare it is to receive pull requests updating the documentation translations(or the documentation) I think that most people won't even notice they were removed.
Then, let's be honest, most of the available translations are partially completed and will never be completed. Therefore I suggest to remove translations and leave only the English one, kept 100% updated.
I agree. My native language is german but I literally write every docu-related part in english (excluding a few guides for local pages and my local knowledge base; but this is mostly for myself only. When others can look at it I write it in english all the time.)
I don't think the translations are a huge issue nor are they that important, though. IMO the most important aspect is that documentation is there, even if it is incomplete or outdated. Many projects don't have any documentation or the authors say "read the source", as means to distract that they don't like writing documentation - which I can understand. After you wrote code, it's hard to switch to "literal and verbose, useful english" again.
Any free time I have available for this project always goes to the code.
That is totally fine too. I would, however had, recommend to also every once in a while work on the documentation. This can be every second weekend or so, half an hour or an hour and then move on with other things. While that does not seem much, if you plot this over years, the documentation will keep on being in a good shape, even if other people report stuff that can be quickly added/changed. For new users in particular documentation is super-important. I always struggle initially when I am before a new project. Once I used it for a while my brain picks up speed-wise, but the initial hurdle exists, and I try to prefer projects that come with some documentation/explanation, even if it is not complete (i can always tinker on my own anyway, but without a foundation this is hard. I don't refer to easyeffects, but to other projects.)
Considering how rare it is to receive pull requests updating the documentation translations(or the documentation) I think that most people won't even notice they were removed.
I think sometimes translations can be useful, for finished products - for instance, a game that is feature-complete. For something that changes a lot, IMO the trade-off is not really worth it. I also think that more and more people will pick up english anyway - the younger folks should all have an ok-grasp of english so that they can use things just fine. And easyeffects probably does not aim for the +80 years old brazil or german grandpa - even though I am sure there are elderly people who speak and understand english very well among the old ones, even without it being their native tongue. (I actually think we'll see more and more elderly people write code too. It's an activity where you can, to some extent, be physically not in perfect shape, e. g. your legs are not as sturdy anymore but you should be doing ok-ish with a computer if your mind is still there. And many elderly people still have a kind of fresh mind.)
TL;DR: I think carrying and maintaining translations may not be worth the time investment. (And if it is important then volunteers can always try to translate if they want to.)
I'm working on optimizing the code in the last days, but when I finish this task and implement some workarounds on the last known issues, I will start updating the documentation. Only in English.
@wwmm do you plan to make a new release soon? I'm updating the documentation only in English and I think it will be ready in the next week.
It could be implemented in the next release.
do you plan to make a new release soon?
It does not have to be soon. So far we have only new features and changes for potential bugs that could happen in very specific situations. So the next release can wait for the documentation update.
So the up to date documentation has been merged.
Some parameters are difficult to understand, but I reported the definition of the original Calf/LSP manual.
Anyway Pitch Faster option is completely missing. @wwmm do you have any clue what it is doing?
Then I found the definition for Release Threshold and Sidechain Reactivity, but I still didn't get them at all. I'd like to go on LSP issue page asking for a clarification.
It's weird that most of the compressors have the Threshold, but the LSP one name it as the Attack Threshold and the Release Threshold is relative, but it's not well explained and changing its value I don't see/hear any difference.
There is an explanation for the faster option in the Rubberband source code https://github.com/breakfastquay/rubberband/blob/2472213d731527a2fadbc56c83a8490ed7e3d78d/rubberband/RubberBandStretcher.h#L261
The reactivity is something I never fully understood. The release threshold I imagine it is related to the signal level where the compressor will remove completely the attenuation. By relative they probably mean that the reference level is a certain amount below the level set in the attack threshold. But it is definitely better to ask sadko about this in LSP page.
Use a method with a CPU cost that is relatively moderate and predictable.
Okay, it's a mode less CPU intensive. And I see it. With only the Pitch and the Limiter on my system, I get cracking sound at +2 octaves and even worse at +3.
Enabling Faster options goes smooth.
This is the default.
But not for us. @wwmm Maybe we should make it the default as well? What do you think?
Maybe we should make it the default as well? What do you think?
I do not see any problem. In the past I favored quality over speed for the default because I did not have any performance issue. But I understand that the Ryzen 3700x isn't the kind of cpu most users will have.
Oh, now I understand why that user complained about the poor quality of our Pitch, we never selected the OptionPitchHigh.