Re: [Audacity-devel] Anyone working on 1.3.5?

[Gale A. <ga...@au...>]

| From James Crook <cr...@in...> 
| Sat, 24 Nov 2007 21:47:32 +0000
| Subject: [Audacity-devel] Anyone working on 1.3.5?
> > 1 -  With foreign languages (at least French and German) selected, the
> > MP3 metadata tags for "Artist Name", "Track Title", "Album Title" and
> > "Track Number" are not filled...
>
> > 2   If you open another file when the first is playing, the first stops
> > playing and starts again from time zero. (regression on 1.2.x)
> 
> > 3  Welcome screen external links and LAME buttons won't open browser
> > properly....
> 
> > 4  Issues where translation of bits of Audacity doesn't work .
> 
> > 5 Metadata Editor not popping up.... If any programmer wants to do
> something better and more elaborate, well why not. 

All added to checklist as essentials. 

>> Shouldn't we add reducing verbosity in Audacity as an essential to the 
> >> checklist?  I'm in agreement with Vaughan that the new interface is too 
> >> wordy.  [If we do, how will we agree on when this item has been cleared?]
> 
> The new stuff is a regression on 1.2.6.  

What new stuff do you have in mind, apart from the Welcome Screen?

> And we do have a precedent that agreed on wording changes get marked 
> as essentials. 

True, but my point is that deciding on wording changes can be 
controversial and time-consuming, even amongst those that think
verbosity is very important. I don't actually see any complaints of
verbosity except on this list, while seeing plenty of complaints of
inadequate explanations. Early days, but I can't find any complaints 
yet about the Welcome Screen on the Forum.

If we come across some particular item and we can agree on a change
quickly, let's do it, but I don't think we have time to do a witch hunt
for such items, marked as an essential, or the time for discussions 
as to when the essential "verbosity" issue is actually cleared.  


> I'd personally like to change the OK...Audacious to OK on the welcome
> screen.  It's not show stopper territory, and maybe I shouldn't be
> worrying about it, but it irritates me every time I see it.

Well there you actually disagree with Vaughan. It's an individual touch,
kind of cute, and I don't care either way myself. But please don't say
this is a regression on 1.2.6. "About" in 1.2.6 has "Audacious".  

> I'd say that if we can agree better (clearer, shorter) wording on the
> wiki then we should still do it, but if we don't agree we leave as is.

I don't get the impression discussing on the Wiki works well for many of
us. You and I like it, but maybe it's better to discuss here, then put
what we *agree* to on the Wiki as a reference point (and then please,
whoever commits the changes, move to "Done"). 
 

> The length of the text in the welcome screens does bother me too.  Too
> long and people won't read it, which defeats the purpose.

Obviously this is a concern but I think you might be exaggerating it
and/or not realising that some users really prefer help to stop inside
the program.  
 
Is your issue the length per se, or the fact that some pages extend
beyond the scroll if viewed in the Welcome browser? We did briefly 
discuss splitting the current text for the longer sections into more
pages, but I presume you decided against. I don't regard the text as
overlong if it was viewed in a web browser, though I'm sure some 
inventive rephrasing could shorten it somewhat here and there. 
If you are really worried I could have a go or maybe Vaughan could 
do it more brutally. The consensus seemed to be "good enough" and 
as you said, we can't go on tweaking this endlessly. 

However as regards the actual meaningful content, wherever it's seen, I
don't think exporting/saving and recording can be much more reduced
without making it less useful. (I would still argue dropping the word 
"export" would substantially help the exporting/saving confusion). 

So what's the answer if we want to prune further? The only one I can 
see is three or four sentences per page with a number of Wiki links. 
There is not really anything suitable on the Wiki that's like a "quick
help" for recording and exporting/saving, but there could be, and that
might be useful to have on the Wiki in its own right. I do wonder if this 
is moving things online for the mere sake of it, but I'd go along with 
having each page of the Welcome Screen short enough not to scroll if 
the user can access all those pages in the Welcome browser. A three 
sentence page in a web browser would look stupid in my view.  


> > Far more important IMO to deal with some of the priority aim
> > tos on the checklist which will (or should) be "known issues" in 1.4.0
> > unless cleared. I would not like to see 1.4.0 released with far more 
> > "known issues" than 1.2.6. 
> 
> So let's hear it then.  Which ones of the priority aim tos should be
> promoted to essentials? 

We are waiting (as regards the Windows release) mostly for the Manual
and translations/translation fixes aren't we? Given that waiting time,
we don't have to only do essentials, do we? Can't we use the time to
look at the priority aim tos that were thought to warrant release-noting?
Of those, I'd suggest we should look at these candidates:

    * Fix: When you close all your tracks and File > Save or Save
       Project As.., no warning is given. Currently there is no
       protection in place for the user inadvertently saving an empty
       project.

    * [JC] Select-all-when-none wherever a selection area is valid is
       not enabled for Edit > Cut and Edit > Copy.

    * Ensure other edit menu items (not just cut and copy) are
       consistently enabled and work consistently. 
 
    * Fix: Old projects open incorrectly - reported by Monty.
      With CVS Head, sample project created in 1.1.0 now correctly
      identifying the real orphans (there are 10), but the waveform is
      still opening as blank. Needs more investigation. 

    * Project irrecoverable after crash if a track is imported then
       another track of *any* description is added after the autosave
       interval (even a recorded or Label Track). When the second 
       track is added to the updated autosave file,  "_data" in
       "projname" is prepended with the name of the first
       imported file. After that the project is irrecoverable, until 
       you change the "projname" back to "_data". 

    * Fix: Make all platforms consistently force Project Rate to the
       rate of imported file irrespective whether that rate is supported
       or not. Currently this does not work on Windows and results vary
       on Linux. QUESTION: Is Michael's issue "1.3.3-beta and newer fill
       the "Project Rate" combo box with several invalid frequencies,
       most likely picking them from a hardcoded list without making
       sure the audio hardware can handle them" part of the same problem?

     * Strongly consider re-enabling PA19 automatic latency correction.
       If not re-enabled, then what should default correction be?
       MM thinks it should be zero (as now) given the "audio to buffer"
       default is 100ms , but GA thinks that means that almost no-one
       will get their tracks aligned without setting the latency correction
       in Preferences, and that this would be a regression on 1.2.x
       where people quite often do get their tracks aligned without
       needing Time Shift Tool. Users of 1.3.3+ quite widely believe
       latency correction "does not work" where it used to in 1.2.x

And possibly (I know you would use this)...

    * Ability to add a label anywhere in a label track by just typing without 
       ctrl-B first, when a selection region of any size is on a single
       track and the track is a label track. (changed so hotkeys worked
       with the focus still in the Label Track).

> > "better coding to prevent memory leaks", 
> 
> Andreas Micheler is taking great care not to break anything with these
> leak-fixes that he has tracked down. I stand by the decision that checking 
> these fixes in now is the right thing to do.

I don't know if we are at cross purposes but aren't the leak fixes being
#ifdeffed and the leaks are not in core code? I was going on this email
of yours:
http://sourceforge.net/mailarchive/message.php?msg_id=473D821A.2000703%40indigo.ie

where you said:

"My view is that we should make the proposed change post 1.4.0 and do
some serious comprehensive leak fixing then. More urgent for us right
now are discussions that help us clear the essentials on the checklist."


>> - How can we reach a decision on mute/solo behaviour?

Will study all this later...


Gale