Hello,
1. In ALSA Latency - #4 by Gale_Andrews Gale Andrews wrote:
The Manual for the next release of Audacity will make very clear that the “Audio to buffer” setting also affects playback.
Could this fact about the “Audio to buffer” setting be added to the FAQ Audacity Manual, in the Playback section? Maybe something like:
_Q: Why do very short audio selections (less than 1 second) not play at all, or only a tiny bit of the end of them plays?
A: In Recording Preferences Audacity Manual, try setting “Audio to buffer” to a lower value. This setting affects playback as well as recording. Values as low as 5 ms may work well on newer computers._
It took me a fair amount of searching to find this answer. I almost submitted a forum request about the issue. I was trying to play an approx. 140ms “beep” sound with “Audio to buffer” set to the default of 100 ms.
Also, I don’t find anything about this setting in the current alpha (2.1.0) manual http://manual.audacityteam.org/man/Recording_Preferences. Maybe the playback effect of the “Audio to buffer” setting should be mentioned there too.
2. How to switch from waveform to spectrogram display doesn’t seem to be indicated on http://manual.audacityteam.org/man/Spectrogram_View. I think the text, near the beginning of the page, that says “Here is the same recording in spectrogram view:” should have this how-to added, maybe like “Here is the same recording with Spectrogram view selected from the http://manual.audacityteam.org/man/Audio_Track_Dropdown_Menu Audio Track Dropdown Menu:”
3. Suggestion: Add an “audacity-doc” package, which contains the manual (Audacity Manual), to the daily-build PPA Audacity Daily Build : “Audacity Team” team. It’s very common for Linux software to have a “-doc” documentation package in addition to the package for the executable. I think that having the manual distributed in this format would be much more convenient for users and would prevent issues like the one in Manual not found in Audacity 2.0 - #3 by edgar-rft
The manual would come from http://manual.audacityteam.org/man/Main_Page since that is the manual version that corresponds to the daily (alpha) PPA build.
4. Maybe the manuals (production version & alpha version) should have the applicable software version number stated on every page (preferably by means of scripting), and/or the URLs should be changed to indicate which manual they are part of. Currently, the main page for the production manual is:
Audacity Manual
And the main page for the alpha manual is:
http://manual.audacityteam.org/man/Main_Page
And there is nothing in either of those URLs to distinguish which manual it is.
Currently, a user could have a printout or locally saved copy of a manual topic, or have been given a URL to one of the individual topic pages, & not be able to tell what software version it is for. Not all printouts or locally saved copies will include the URL, so I think there is some value in including the version number in the text of the page.
5. Suggestion: Make the alpha manual easier to find …
a. … on the website. Currently, if someone navigates to http://audacityteam.org/ and clicks Online Manual, they get the manual of the production Audacity version Audacity Manual. From there, they have to guess that they should click Wiki (which, until the user mouses over it to find out the URL, might be assumed to be a link to the current page, since the production manual may be recognized by the user as being a wiki) and only there (Missing features - Audacity Support) is the alpha manual listed.
A solution might be to add to Audacity Manual a box, similar to the one on http://manual.audacityteam.org/man/Main_Page that starts “This online Manual is only for …,” directing alpha users to http://manual.audacityteam.org/man/Main_Page.
b. … in the alpha version of Audacity. That is, have the “view the content online” link in Help > Manual point to the alpha manual rather than to the production manual.
6. The closest thing that “Help > About Audacity…” has to a build ID is a build date at the bottom of the Build Information tab. Maybe a date, as opposed to a revision-control commit ID, is OK since perhaps your team members only need to know whether a user has the current version, but at least the build date could possibly be put at the top of that tab (and preferably right under the version number at the top of the Audacity tab) so users can easily find this info for support requests?
For instance, a user could be running the daily PPA version (since multiple 3rd-party blogs point users to this), but have turned off that PPA in their APT client (Synaptic or other) because they don’t like being prompted frequently to download an updated revision. Then maybe the user forgets that it’s been turned off, and subsequently they ask for support on the forum. There are other similar scenarios as well. The obvious version number (currently 2.1.0) wouldn’t be enough to tell support staff that the user doesn’t have the latest revision. Having the build date or ID be prominent would assist with this.
\
In some of the above suggestions, I have used the URLs for the production (currently 2.0.6) and alpha (2.1.0) manuals sort of interchangeably. I realize that where I have suggested that a change be made to one version of the manual, maybe the team will want to change the other version.
Thanks for your attention.