Talk:Feature Requests

This page is only for discussion of the Feature Requests page itself. This includes design of the page, the voting process and so on.

Fades to a "target" level

Additional Choice of fade to a target dB, not by an amount (17 votes)

• Steve: As currently written, this feature request makes no sense. A fade effect cannot determine the start or end amplitude. For example, if a selection ends at silence, then no amount of fade will change that level from silence.
  • Gale: I think many are quoting "0.8 to 0.2" simply because the default vertical scale is like that; nine of these (included below) asked for "80% to 20%" or similar. A fade by a specified dB gain on silence has the same "problem". Your "Adjustable fade" (as it appears to the user) sets the start and end amplitude (you call it Maximum and Minimum). The start amplitude of shipped Fade In is "0%". The end amplitude is "100%".

    I also disagree with discarding votes for a % change. Text Envelope has this feature. I don't think "% of original level" is very ambiguous.

• Steve: My "Adjustable Fade" effect set the Max and Min Gain. That is the distinction that I'm trying to make. Regardless of whether it is dB, % or 0 to 1, a fade will adjust the initial and final gain rather than the initial and final amplitude. I am strongly in favour of a fade effect that is able to control the initial and final gain, but controlling the initial and final amplitude is highly problematic.

  I'm not suggesting discarding votes for % change (though I much prefer dB change as I believe it is less ambiguous). I'm suggesting discarding votes for "target level".

  • Gale: The problem is (as I said) "as it appears to the user". Your plug-in can fade to a target of -6 dB fine, if you input the correct gain for the audio. Envelope Tool can fade to a target level, except you cannot see exactly what you are doing (especially with Waveform scale). A lot of these "target" request come from dissatisfaction with the Envelope Tool - at best I might move the requests into Envelope Tool, though clearly the requests are really for what they say (a plug-in).

    A demo plug-in by you already implements target fade. Such a plug-in has the same restriction that shipped fades have - they have no effect if user selects silence. Custom Curve in "Adjustable Fade" has the same "problem" that you complain of in a target dB plug-in - if user sets a maximum gain > 0 and the audio is already at FS then user will get distortion.

• Steve: It only achieves fading to a target level by specifying an initial and final period for the target level to be appear in. It does not aim to achieve the target level at the start/end points of the selection, but in a period at the start and end of the file. As the plug-in demonstrates, achieving a target level within a specified time period can be achieved, but that is not what this feature request says.

  To clarify may point about it being "impossible" - Unless a time period for the target level is specified, the resulting fade is very unlikely to be what the user wants. This feature request does not consider that vital fact which I presume is because novice users requested this feature without considering what it would mean in practice. If this feature and its votes are to stand, it must take account of the practicalities. I have posted a new (worthless) demo plug-in on the forum that does exactly what is being requested and clearly demonstrates the problem.

  • Gale: Last week I sent "AmpFadeToTarget" (that specifies the length) and the "worthless" variant to seven people who wanted "target" fade. Only two have replied. One said "the worthless one is fine, except the guy didn't bother to make it work on stereo tracks. I deal with scientific tones and pulses and that's all I need, not all those length choices".

    The other person (not very "advanced") takes the point that the worthless version mostly distorts on real music, but is confused as to why acting on a point distorts, about why specifying different lengths in "AmpFadeToTarget" affects the result, and about which length choice gives the "correct" result. I note that "AmpFadeToTarget" has had a reasonable number of downloads. Therefore it occurs to me that one option for developing a "target fade" might be not even to expose the length choice to the user, though in fact changing the length gives a lot of flexibility in the results you achieve.

Interface tweaks / extensions

Gale: This distinction doesn't work for me. a) users can't reasonably be expected to choose whether something is a "tweak" or needs a lot of coding/testing. b) it cuts across obvious GUI elements like Toolbars and Preferences which need to be kept together. I have removed the distinction; instead the interface sections are based on GUI elements and behaviours.

Highest-rated

Gale: Too much work to maintain, and means that the same item can easily get voted for both in "highest rated" and the main section of the page. Answers: have a separate "votes" column which can be sorted? Add a symbol to items with more than a particular number of votes, and search for the symbol?

I made a try for a sortable request. If you click on the little icon on the right, the list will be sorted. --Djiboun 08:32, 2 October 2010 (UTC)

Editing suspended?

I have received a request to place some votes for the following features:

Bind effect parameters to buttons or keyboard shortcuts: including particular settings thereof e.g. one keystroke to amplify + 3 dB, another keystroke -3 dB, another to compress

Allow real-time effects

Markers on Waveform Ability to drop vertical marks that are 'glued' to the waveform on the main track http://forum.audacityteam.org/viewtopic.php?f=20&t=11734&start=0#p46431

The user was unable to place their votes as it appears that editing of the page has been suspended.

Gale 27 Jul 09 16:59 UTC: Please see this answer on the Forum.

Needs splitting?

• Gale 20Jun08 01:35 UTC: I think we're getting more organised now about moving requests in here from other sources (especially with Peter's help from the Forum), but this page is getting very long. I can move some things out to the "experimental" section of Completed Features, and no doubt some trimming of similar comments could be done, but should we think about this page containing only "Highest rated" and links to four or five individual Feature Requests pages? I'm never much in favour of splitting until it becomes unavoidable, but we may be getting close to that. Or, can we get away with each section having a link back to the TOC, and/or simply grouping the sections on this page?
  • James 02:23, 20 June 2008 (PDT): I see significant work in splitting. I don't think it is essential. Time invested in it might be better invested in making the Lame Installation more foolproof / more flow-charty. I think we can get away without splitting. We could split incrementally, e.g. we already have a section 'Automation'. We could 'take out' Effects in the same way. If it's easy to add a new namespace like 'Feature Requests:' that could be a good idea for the extracted page(s). In the longer term my preference would be for the Feature Requests page to be a TOC, with on the TOC page a boxed developer written commentary for each section. That would at least tell visitors that their feature requests are being read! Top requests should still stay on the page.
  • Gale 21Jun08, 08:27 UTC: Re: Lame Installation, I see room for improvement in the Windows section (was built up piecemeal from 1.2.x only text), not in Mac/Linux, and probably the page should end at Linux and the rest either go to MP3 or a new MP3 Tips page.
    • James: Yes, MP3 Tips would help the main installation page be clearer. It's the highest traffic page, so worth the effort.
  • Gale 21Jun08, 08:27 UTC: Re: Feature Requests I guess longer term we're saying the same thing (not a Wiki __TOC__ but a custom page of links to individual pages each dealing with groups of Requests)? I was looking to do the split sooner than that, and I don't think it would take that long, and I or Peter would do it. Something like four pages:
    • Analysis and Measurement
    • Recording and Playback
    • Editing, Effects, Importing/Exporting
    • Interface, Resources and Automation

• I don't think we especially need a namespace, AFIK we can start the page title with "Feature Requests:". Otherwise some way of navigating the sections will be needed, to say nothing of the page size (at 100 kb we might actually start getting editing issues on slow set-ups).

• James 03:45, 21 June 2008 (PDT): OK. Try splitting one category out. The template at the top of that page should have a link back to the main page, plus link to instructions for voting - and may need some iteration. Whichever section you split out, on the ToC page I'll have a go at adding some 'summary text' that tells people where they are going - something like:

  Effects: About 18 requests for new sound effects, including supporting 
  DirectX, Convolving, Deverb, an effect for matching EQ and a VCO synth.
  This section also has about 24 effect enhancement requests, asking
  that frequency range be extended, alternative presentation of parameters,
  changes to how presets work and suggestions for higher quality algorithms.
  

  This achieves two things. It helps people to add new requests in the right section, because they can quickly get a sense of what is there (by example rather than by 'definition'). It helps us to keep tabs on what requests we've got.

• Gale 22Jun08,08:30 UTC: Thanks. I'd prefer to split all at once to prevent user confusion, though. Effects "could" be separate, though I'd rather have no more than four of these pages. A fully descriptive box for each would be great, but I think what you're suggesting may be too specific/need updating too much. Alternatively we could have four, maybe five sections on the main page. That would really help, the feedback I get is that this page is a maze, and you lose focus with the large number of sections before half way down. I think I'll still try and tidy/prune before doing anything major.

• Peter 23Jun08,09:53 BST: I agree with splitting the page. I think that the size that it is now makes it intimidating for readers - and makes it difficult to find the right section. It also makes it harder to edit too. Breaking it into Gales suggested 4 sections would have the benefit of steering users to the right sub-section more readily - it makes them think a little bit. Building on James' suggetion re retaining the top-voted request on the main page - I would prefer to see a fifth section created for the top requests, - this would keep the top level FR page a lot cleaner. And yes, I can undertake this task if required - but probably not in the next two weeks while Wimbledon is on ....

Sponsorship?

• I've removed the request for sponsorship of features. To my knowledge it has never been taken up. It makes the whole project look more commercial than it is - so it is doing more harm than good. Where we've had sponsorship it's in the form of a company that wants a variant of Audacity, and they have contacted Dominic directly. James 04:24, 25 February 2008 (PST)
  • It depends how much money we'd want I think. I have reservations too but I don't think we should necessarily remove it just because with the suggested page redesign the best place to say it may be at the top and then we're embarrassed about it being too prominent. Without wanting to quote money in the text, would we say do one of the interface tweaks proposed for $100 (a sort of sum a private individual might come up with)? As phrased, it did rather look as if we were inviting commercial sponsorship of the custom version sort. However I can recall several instances where we have been offered a hundred dollars or so on -help list to do particular things. A point for ourselves (and possibly influencing whether in practice this might happen) would be whether the money should be shared between the coder and the project, or what exactly would happen. Gale
• The reason I removed it is because it was doing more harm than good. If we had a system like wxWidgets bounties  and five or six live at a time, like they do, then I could see some point. However, we are a different kind of project and bounties don't work for us. Can they be made to work? I personally don't think so. Perhaps worth a wider discussion?? In the absence of a better set up that would make them work, the request was doing more harm than good. So I removed it. Logical? James 14:38, 27 February 2008 (PST)

• I still don't have very strong views, so I am not arguing, however I don't see the actual *harm* (as opposed to good) it does, if it is sensitively phrased. If we got only one more "Umixit" out of it, I'd say it's worthwhile. I don't think we're well motivated currently. It's possible some kind of bounties might increase motivation, but there's a risk they could divert what coding we do away from bug fixing and releasing which is the short-term concern. My gut feeling - Joe Public is not as opposed to our being commercial as you might think. Hence more than a few user comments that we should be more aggressive about encouraging donations, so as to move a bit faster with releases and features. Raising the profile of donations on the web site is something I want to raise again on the list presently. Gale

Voting Systems

Audacity suggestion board, compliments of FeVote.com. :)

Micropat 23:48, 26 September 2007 (PDT)

Although we had an alternative Beta Feature Request system in place intended to make voting easier - there is some feedback on that system here - unfortunately the script that operated the system did not prove to be reliably available. In the longer term we may introduce a new more interactive Feature Request system on our main website.

< Back to Feature Requests

Real-time Eq

I think that this feature should be a separate item to the other "Real-time effects" request. While real-time effects in general are a much requested feature it seems unlikely that this will be implemented for quite some time.

Real-time equalization is a special case in that it may be possible to implement this without having full real-time effects support. Almost all media players include a graphic equalizer that work in real time. Even the ability to "bounce" a track through a real time Graphic Eq would be better than the limited "effect preview" that we have now.

It is extremely difficult to apply equalization effectively without being able to hear the effect as you change it, but this is one of the most basic and common of all audio processing tasks. I therefore think that real-time Eq should be considered separately from other real-time effects requests.