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