On 23/02/2012 00:42, Gale Andrews wrote:
>> On 21/02/2012 22:52, Vaughan Johnson wrote:
>>> Thanks, James.
>>> Are there any specific areas we know haven't been addressed?
>> There are only 4 workflows which we know to have been tested.
>> As other workflows, it would definitely help to have someone who does
>> batch operation and/or timer recording to be bashing away at it, though
>> I am not expecting anything there to be a step backwards from 1.3.14,
>> more likely just stuff we hadn't noticed or recorded in bugzilla until now.
> Batch has many undocumented bugs and missing features.
I meant batch-chains (now just called chains) rather than
batch-scripting (now just called scripting). I'm doing that, that is
using the wrong word, way too much these days. Sorry.
If chains is very buggy, then maybe we should disable it until we have
time to work on it.
> Importing files and moving bits between them (in the same or different
> projects) is quite a common workflow. That would I assume have been
> tested heavily for bug 137 already?
> I understood that Peter used Timer Record heavily. There is a bug
> open that Timer Record carries on recording after time is up, still
> occasionally reported.
> I have not heard anything bad from the people I e-mailed privately,
> except intermittent refusal to save project.
That would be very serious if the ability to save doesn't come back
and/or he can't export.
> That user's workflow
> would be similar to Peter's but not organised as to doing the same
> edits every time. He plays and listens then tweaks volume, EQ or
> other effects as needed. However he religiously does CTRL + S after
> every edit. Possibly this conflicts with autosaving (?) but I don't
> think that explains all save failures (not mine, anyway). He is on
> Win 7, 4 GB RAM, I do not know the GHz.
> I would have to ask to publish other people's workflows on the web.
> I know some of these workflows. Is it worth publishing anonymously
> on the Wiki? Better of course to get the people to join Wiki.
Indeed, the better option is better. We need a pool of tame testers who
are keen/eager to try out rcs, and who actually are interested in
staying with us at least somewhat between release cycles. The
anonymous/ anonymized workflows aren't informative enough to be
published on wiki. It's named people, who we can add info (like YES
Norton AntiVirus was running, NO scanning of the project directory was
disabled) that we need. The only reward we can really give them is more
of an inside track. We're working to resolve issues that matter to
you. If you're helping us with actual bugs, and we understand your
workflow, we are much more likely to address P5 issues, including
enhancements, that matter to you.
> Bruno and Koz on the Forum may have a workflow we could publish.
Bruno, Koz, if you are here reading this please comment. I'd really
>> We possibly should look at improved release notes for missing microsoft
>> redistributables. It's a problem developers won't see since they always
>> have the redistributables. I don't think we can or should do much to
>> try to fix it this time round, though for 2.0.1 we should look at
>> whether the installer can detect it and even fix it. I don't actually
>> know it is a problem this time round.
> You mean "application configuration incorrect" on XP? It still averages
> about 4 known reports per week.
> We could have a release note, though it would have to be a WONTFIX
> unless we can actually do something.
We can. We can detect it in the installer and either include the redist
in the installer and apply it, if needed, or give a what-to-do message.
> About 20 times more people read the Manual FAQ's than Release Notes,
> so I was going to put a Manual FAQ up for it as soon as the freeze is
Perfect. Hey Gale, it is awesome what you are doing with Audacity for
us - the depth of knowledge about what is going right and what is going
wrong and the sheer amount of hard work really shines through,
throughout this e-mail.
> 250 kb usually implies about 50% - 75% complete. On the basis that
> only some eight translators regularly offer .po files, we have about
> 40 not complete translations. We shouldn't claim anywhere (any longer)
> that translations will be complete for all languages.
lists "supported non-English languages (48)". It indeed does not claim
they are complete.
>> I do think, as this is a major release, having the French translation checked
>> would be good - especially checked for word-overflow problems - (is a string
>> like "0100 h 060 m 060 s+.# échantillons" too long?) - and if there is a P2
>> translation/sizing problem with French, you Vaughan could make a call as
>> to whether to roll in a change as part of another respin done for any other
>> reason or demote to P3.
> I already check languages quite heavily as the main person who commits
> the .po files. I added that to my Wiki workflow.
It's great that you do that. In terms of identifying gaps in what we
currently have the resources to do, we still need native speakers to
check too - not just the person who wrote the translation. If the
Chinese translation has a menu item for "A boat Audacity" I'd like us to
know and get it fixed. And although I can't think of a concrete example
of it, there may be things that lie between translation-bloopers and
word-overflow that a non native speaker can't check. There is a lot of
work just in checking for word overflow in all 48 (or 31, or 8) languages.
> "Samples" in timetext controls is not an issue, except that (in any language)
> if Audacity is used in an unmaximised window (such as the size it initialises
> to on fresh .cfg) and the format is changed to samples, Selection Toolbar
> is truncated.
> I don't know what you could do about that, short of allow "Audio Position"
> to move down?
I've tried it, and that's OK. Even so, what I am writing about is less
about this example (as it happens non)-issue, than about communicating
to Vaughan the kinds of thing that can easily slip past us with the way
we are currently forced to work.
> The known overflow issue for French and other languages (P3) is in
> Preferences on OS X and Linux (because those systems have larger
> default fonts):
> http://bugzilla.audacityteam.org/show_bug.cgi?id=295 .
Ah. That's a little trickier than I had thought it would be. Let me
think about what to do about it.
Thanks again Gale.