Talk:Feature Requests

From Audacity Wiki
Revision as of 16:24, 1 February 2017 by PeterSampson (talk | contribs) (Highest-rated: moving the long enote to the Talk page)
Jump to: navigation, search
This page is only for discussion of the Feature Requests page itself. This includes design of the page, the voting process and so on.


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)
Gale 29Jan17: I still think "Highest Rated" is arbitrary and unhelpful because it ignores subvotes within logical sections that may have high vote count. A notable example is "Export to directory from which original .aup or audio file loaded: (like Save Project does) ... (36 votes)" which is not in "Highest Rated" at all. There are plenty of other items with > 10 notes not in "Highest Rated". Also "Highest Rated" makes it harder to add votes, because the logical grouping of items has been split up. For example, we've now lost the connection between "Beat matching" and "adding bars and beats to the Timeline".

The subvotes (e.g. 20 of the 35 who want feature a) suggest it should be done by method b) ) may make any sorting even in a WikiTable impractical. The best suggestion I have is to put high votes in coloured divs, or find a way to give them some property which we can search on, and retain logical grouping.

  • Peter 29Jan17: I started work on bubbbling-up highly voted for ones following the recent discussions about alternative tools for handling FRs (given that I have some spare time while the Manual is frozen/semi-freddo). My POV here is that we have always had the Highest Rated ever since I've beeen with Audacity so I am just continuing that tradition.
    • And yes I agree that it loses the "logical grouping" but the way I see it is that if we were to reatin logical grouping we would tend to lose high-rated items in this massively TL;DR page - even with highlighting. But I'm happy if you want to do the work of restoring these "Highest Rated" to a "loggical grouping with shading" and with a suitable search tool to find high-rated ones quickly.
    • I do take your point about the blurring of votes when counting. The following note is an example of one. From this entry I have no idea of whether the 32 votes for "Save Changes on exit" includes the 17 votes for "Save Changes? on exit, subject to conditions" - so I really can't tell if this is a 32 votes or a 59 votes or some figure inbetween. But what I van infer is that this is one of the much-voted for items and so would deserve to bubble-up or be colour coded in situ.
* Warnings:
    • Disable "Save Changes?" on exit: (32 votes) Simple option, even if the file has been edited. Use case is importing files to play them, view them or analyze them.
    • Disable "Save Changes?" on exit, subject to conditions: (17 votes)
      • If user's last action was to export the complete audio (not a selection) (11 votes)
      • If user had not edited the project/had only imported files (4 votes)
      • If user had only done "safe" editing that would not materially harm the audio, e.g. no length changes but normalizing or amplifying to "see the audio better" is allowed (2 votes)
      • If the only content was imported files located in the system temp location (1 votes)
          Users are well known to delete files on import as part of their workflow. To be safe, this option must either not be exposed in Preferences (only be available by editing audacity.cfg) or be hidden behind an "Advanced" dialogue, or only be available if all the audio has just been exported.
  • But this is a slightly specious exercise anyway (as I have pointed out before) as I don't believe that any developer ever looks at this page to decide what they might implement next (based on real life user needs).
  • Gale 29Jan17: I didn't notice you got any consensus on bringing some of the highest rated to top here. The Highest Rated section is now really misleading to a developer skim reading, because it "looks" complete, but obviously is not so. I think (on this page) Steve has in the past agreed with my misgivings about Highest Rated.

    From comments on -devel e.g. Mark Young, Joel Bouchat, some developers do look at this page not for highest rated but for requests related to what they are working on (Timer Record, Chains and Exports in their case). For them at least, logical grouping is more important - an item with only a few votes may still be something they want to implement. Unfortunately because you commit all your changes individually, it's now a big task to undo what you did - if we want to undo it. I suppose I could undo it piecemeal when working on this page.

    Search queries would need research or may need an extension, which Buanzo would have to approve. I don't have a specific idea right now. Coloured divs would work if you were prepared to scroll the whole page.

    As a general rule, if a vote count has further indented bullets below it, those indented bullets are part of the total vote above and not additional votes. We can say 49 people want to disable save changes on exit, because 32 and 17 votes are top level bullets. We can't say "Disable "Save Changes?" on exit, subject to conditions" is 35 votes, adding votes together for the top and lower order bullets. The problem with saying 49 people want to disable save changes is that we lose the rich detail - Steve has complained before when we lumped all similar items together without noting differences in the comments.

    • Peter 30Jan17: I've been thinking about this some more and I'm coming round to thinking that organizing by "logical grouping" does seem to maker sense (particularly taking on board your comment about Mark and Joel).
      • I was working yesterday , as you say without consensus, on my long-held understanding (I'm sure I saw it documented somewhere, but can't find it right now) that ant item with greater that 10 votes was a candidate for Highest Rated, which is why I added the others yesterday. But I can revert that (see below).
        • Update: ah now I see from editing the Highest Rated section ther is a hidden comment whicj clearly says: "Anything with 10 or more votes can be moved here by cut-and-paste. If possible, put those with the highest votes on top of the list." - so I was only following instructions ...
      • If we do reorgaize entirely by "logical grouping" than I really would want to adopt your suggestion of a colored box to indictae the highest rated within each vertical group. Do you want to create a new div template for suchlike, or should we just use the existing note div?
      • Maybe we could create a custom TOC at the top to index all the highest rated items, if that's not going to be too much work to maintain.
      • I'm thinking thatn 10+ votes is too low a threshold for highest-rated candidacy I'm thinking that 25 or 30 might be a better criterion.
      • So my first step today will be to revert the additional promotions that I made "without consensus" into Highest rated (and that'll thin it out a bit). But I think I'll retain the reordering I made in the pre-existing Highest Rated by vote count. I'll experiment with removing the H3 headings that I added (as they clutter the auto TOC) and pro-tem replacing them with an enrobing note div for the items.
  • Peter 30Jan17 later: OK so I:
    1. restored the page to as it was before my edits yesterday (so no promotions),
    2. ordered the Highest Rated section by vote count,
    3. reformatted Highest Rated so that each entry stands out clearly - with a double line space between entries,
    4. experimented with a Custom TOC (hidden in an ednote for now - I'll release this into the wild if you think it's useful),
    5. experimented with enrobing one entry in a coloured div (note div for now),
    6. set P1s for two entries that should be movable to Completed Features: Scrubbing and Ediit While Paused.
  • Gale 30Jan17:
    • The suggestion to cut and paste Highest Rated was HTML commented out, which meant "don't do it any more for now". So I made it a visible ednote to say that explicitly.
    • Thanks for the reversion - I forgot about overwriting with an old edit then adding back what we want to keep.
    • I don't like the Highest Rated section being ordered with highest vote first whereas before e.g. on 06Jan17 it was not. So for example the separate but related votes for "BPM and beat timecode automatic detection and beat matching (66 votes)" and "Let the Timeline display time signature and bars/beats (36 votes)" are no longer together.
    • I was thinking too of putting into Highest Rated anchor links to the original material and the original material is left where it is. I would go farther and make the Highest Rated section contain nothing but links. Rather than you do undo your ordering of Highest Rated by vote count, I would over time move the Highest Rated material back into the main list. This makes it *much* easier to find where to add votes.
    • I agree 10 votes is too low for the Highest Rated threshold. Maybe 25 votes? But if we do this, the list must be complete, not selective as it is now, otherwise it is just misleading. There would be a lot of links. There are ways of collapsing the list, I think, with a collapse/expand button. Screen reader needs might need to be thought of. Or, make this Highest Rated list of links a separate page.
    • Ideally the Highest Rated links would show the number of votes and be ordered as highest votes first. We could add an instruction to editors that if a vote count is increased to reach or exceed the threshold, add a <div id> and link to it in Highest Rated. If the vote count is already over the threshold and is increased, adjust the vote in the Highest Rated link and adjust the link order if needed. I don't think that is too onerous.
    • Yes to give colouring of Highest Rated in situ a fair trial, it would probably need some special template. But at the moment I'm thinking Highest Rated as nothing but a list of links is a better solution.
  • Peter 31Jan17: Replies to Gale on how we move forward:
    1. I now have come round to the idea of moving the Highest Rated items back into their functional categories. I am unsure in many case of wher to move them bto so here is my suggestion: IF you annotate the Custom TOC display texts with the functional section you want them to go to, THEN I will do the work of moving them back.
    2. AND As I move them into their functional section I will remove your temporary text and replace it in the custom TOC with a vote count.
    3. Once that is complete it will be a neasy matter to redorder that custom TOC in any order you like simply by moving the entries around.
    4. I've been doing some thinking about the entry-level criterion for membership of "Highest Rated" custom TOC - and I'm thinnking that while our original 10 is too low, maybe 25-30 is a bit high. From looking at the existing list I would suggest 20 as that includes stuff that often gets mentiuoned on the Forum like "Monitoring on by default. But then again maybe 25, as you suggest, hits a sweet-spot as we don't want an overly long HR list.
    5. It would be an easy matter to raise the entry-level criterion at a later date by just removing them from the custom TOC (and removing any coloured box wrapped around them - if we do that.
    6. Once we have decided on the entry-level criterion, and once the moves to functional groupings has been completed, then I will comb the rest of the FRs identifying other HR candidates giving them an ahchor and creating an entry for them in the HR custom TOC.
    7. I'm open at the moment about whether or not we create a daughter page for highest rated custom TOC - but my inclination is to leave it here. Let's see how long the list grows, or shrinks, to once we have done the above work and then make a call on this.
    8. "Yes to give colouring of Highest Rated in situ a fair trial, it would probably need some special template" - OK so do you want to go ahead and create the special template and I will do the enrobing when I move each one back to its functional grouping.
  • Peter 31Jan17 later: Gale, I've been reading the Talk page and just noticed your suggestion from 8 years ago of splitting the page into functionally grouped daughter pages Needs Splitting. This is eeming like a jolly good idea to me, do we want to go ahead and do this while we are working on this key page?
  • Peter 01Feb17:
    1. Today I combed through the Feature Requests page for all entries with 25-plus votes. For these I added an entry in the HR Custom TOC which incluse their vote count (note that that will give us two places to uodate vote counts - but I can live with that).
    2. This has almost doubled the number of entries in that custom TOC, now at 5o or so entries - which leads me to thnink that 25-plus is probably the right selection criterion.
    3. The size of this HR list reinforces my desire to implement your earlier proposal to break this page up into functional daughter pages (as I discussed yesterday in this ednote).
    4. If we do settle on 25-plus as the eligibility criterion - then a few of the pre-existing entries will be demoted.
    5. I'm also thinking that it would make sense to break up the Highest rated by functional grouping too.
    6. Gale, do you want me to start moving entries back to their functional groupings, out of the Highest_Rated section? I can probably wor out pretty well wher most of them should go - I can ask you about any I'm unsure about.
    7. I'll start work now on adding votecounts for the pervious entries. - DONE
    8. From looking at the relegation candidates (see below in Custom TOC) I'm thinking that we may want to set the HR eligibilty criterion to be 20-plus - thoughts?

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 ....


  • 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 :)

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.

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

Peter: thhis section looks to be redundant - we no longer have a section like this on the page.

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.