Use Cases voting
When individual requests were amalgamated into a use case, we lost the votes for those individual requests (OK, they are recoverable if there was any point doing the work). The azimuth checking still has the possibility to vote for the specific request on the Feature Requests page (perhaps that ability to vote for it should be transferred into Use Cases). Would it make any sense in our link to this page on Feature Requests, to suggest people might want to vote either for parts of a case, or for a whole case as an entity? For example, some elements of Audio Cleaning might have greater popular appeal than others. - Gale
- I think the purpose of voting is to draw the attention of developers to the feature. For me Use Cases already does that. I see use cases as cogent arguments to me to implement a feature - and that is a step beyond simple voting. Visitors enjoy voting, but it's probably enough that they can do it on the features page. I've no problem with some technology requests (e.g. weeks-and-days in the time-ruler, which would be for the noise-litigation use) appearing in the feature requests too, where they can get voted on.
- Declip - is this the declip in the SWH suite? I have found that personally of very limited use except in very severe cases where it would be better to re-record anyway. The Nyquist declipper is of much more general help IMO and there is a good case for adding it to the default plug-in set.
- Raise again on audacity devel. Could be helpful to someone proposing noise-cleaning.
- Advanced preview - I would suggest another feature that could be useful would be a button to hear the selection dry (unmodified). I quite often find that although a preview with noise reduction applied sounds OK in isolation, when I apply the effect and compare it with the original, there is sufficient degradation compared to the original that I go back and redo the noise removal with weaker settings. Ability to mix wet and dry within the effect (so masking some of the degradation) might be interesting too.
If you want to add to azimuth setter can you do it here? I think perhaps it does need more explanation here because your clarification where you summarise it on Feature Requests "displays tape azimuth setting before and during recording" leaves me unclear (if no-one else) as to how Audacity can measure this without recording from the tape player.
The more I look at this Azimuth Setting 'use case' the less I like it being here. Perhaps it can be given a page of its own and cut down to a much more concise version here. I think the use case is in any case 'Recording from Tape, LP and Radio', and Azimuth info is one of the technologies to mention to make it better (for tape).
I'm unclear where the problem lies. Audacity sees the audio input before it begins recording, and obviously azimuth is set before recording, not normally during. NT 16:27, 26 October 2007 (PDT)
Hi NT - when does Audacity see the input before recording, when it monitors? That's OK if that's what you mean. If you don't mean that then I do think you need to clarify in the summary of it on Feature Requests and in detail, on Use Cases. I understand it as expressed on Use Cases (which I did not change at all), it is just the change you made on Feature Requests which brought in the concept of azimuth being checked before recording. So I think perhaps you should clarify in Use Cases that you are checking before recording (as well as during it).
Also I am not really clear (and not everyone uses cassettes these days) why you would adjust azimuth (a substantial operation with screwdrivers) for every tape you play. Is it that the heads go out of alignment quickly? Or would very small manufacturing differences in the tape housing, pressure pad and so on mean that a perfect azimuth for one tape is not perfect for another tape, even though the head alignment may not have moved? I do think this needs a strong case making for it, and if this is something that many users would not do frequently, or something that does not change frequently, it might make the case weaker.