Bugzilla – Bug 697
Incorrect naming of Compressor 'release phase'
Last modified: 2018-08-20 11:45:23 UTC
Created attachment 461 [details] Replace the word "Decay" with "Release" As per http://en.wikipedia.org/wiki/Dynamic_range_compression#Attack_and_release the period when a compressor release the gain after the level has fallen below the threshold is called "release" and not "decay". The term "decay" properly applies to amplitude envelopes as used in some synthesizers, not to the release phase of a compressor,
I'm absolutely behind changing the UI naming, but I think the patch (which changes all the variable names) is overkill, generating code churn on the way. It also breaks existing preferences, by changing the name there, to no great benefits. Could we have a minimal option to change just the UI text and the comments as appropriate? Would avoid lot of internal code change, mess for plug-in authors and so on, which won't actually benefit users at all (because they never see any of the code names).
(In reply to comment #1) Richard wrote: > Could we have a minimal option to change just the UI text and the comments as > appropriate? +1. Include a comment that says the label name was changed?
Created attachment 462 [details] Update strings and support old Chains (In reply to comment #1) > I'm absolutely behind changing the UI naming, but I think the patch (which > changes all the variable names) is overkill, generating code churn on the way. > It also breaks existing preferences Except that if a user looks in audacity.cfg they will not find the "Release" parameter. If we are to be concerned about backward compatibility, then perhaps compatibility with old Chain scripts should also be maintained? This new patch updates strings, leaving variable names and preferences unchanged and provides compatibility with old Chains.
(In reply to comment #3) Richard wrote: >> It also breaks existing preferences Steve wrote: > Except that if a user looks in audacity.cfg they will not find the > "Release" parameter. Using your first "Replace the word "Decay" with "Release"" patch, if user looks in audacity.cfg after using previous Audacity versions they will find "ReleaseTime" and "DecayTime" parameters which may be even more confusing given the action of the control has not changed. As most people who know the merest thing about compressors will know what "Decay Time" following "Attack Time" does, I suggest leaving the .cfg parameters alone. There are plenty other parameters in .cfg that bear little resemblance to the control name.
Comment on attachment 461 [details] Replace the word "Decay" with "Release" > I suggest leaving the .cfg parameters alone. OK, so you prefer the "Update strings and support old Chains" patch? Marking the "Replace the word "Decay" with "Release"" patch obsolete.
(In reply to comment #5) Steve wrote: > so you prefer the "Update strings and support old Chains" patch? Yes, because it's less invasive and lets Chain files from old versions still support the parameter concerned (thanks for that). For completeness don't we need an analogous function under "// restore deprecated commands in chain script" in BatchCommands.cpp so that user can go back to a previous Audacity and have the parameter obey its setting?
(In reply to comment #6) > For completeness don't we > need an analogous function under "// restore deprecated commands in chain > script" in BatchCommands.cpp so that user can go back to a previous Audacity > and have the parameter obey its setting? As a matter of policy I believe that would be counter productive. For example we would not have been able to replace G-Verb. Regarding this case specifically, I do not anticipate any demand for such a feature, but if there is then we could consider ways to implement it. In my opinion it is of more benefit for users to focus our efforts on improving Audacity, then there should be no reason for users to downgrade.
(In reply to comment #7) > there should be no reason for users to downgrade Probably there will always be some reason to downgrade for some users. Windows users upgrading from 2.0.4 to later versions who want low latency without ASIO have got to go back to 2.0.4. Users upgrading from 2.0.0 to later versions who need RAM caching need to go back to 2.0.1.
(In reply to comment #6) > For completeness don't we > need an analogous function under "// restore deprecated commands in chain > script" in BatchCommands.cpp so that user can go back to a previous Audacity > and have the parameter obey its setting? To answer your question directly, no I don't think we need to do that. We've never done that before and it is not specifically relevant to this bug fix.
(In reply to comment #9) > We've never done that before I was looking under "// restore deprecated commands in chain script" in BatchCommands.cpp where we have done it before. It seems a shame to break a users Chain because of the desire to rename something that is not a known source of misunderstanding. But I know forwards compatibility is less important than backwards, and users of Compressor may be a little savvy. So if you don't think it matters, mark the patch "ready" (I already tested it) and we'll see if others think any action is needed.
(In reply to comment #10) > I was looking under "// restore deprecated commands in chain script" in > BatchCommands.cpp where we have done it before. Ah yes, there is that, but iirc that was intended to be only a temporary measure until Export format options were implemented. > But I know forwards compatibility is less important > than backwards, and users of Compressor may be a little savvy I agree. (and users of Chains are likely to be a little savvy too.) Marked patch_ready
Fix applied in rev 13008. I agree with Steve - backwards compatibility (for a while) is positive for users, forward compatibility is not needed and a waste of effort. I have noted when the backwards compatibility went in, in the hope of taking it out in a few versions time to avoid an ever-growing list there.
