On 12/1/2010 6:53 AM, Gale Andrews wrote:
> | From Vaughan Johnson <vaughan@...>
> | Tue, 30 Nov 2010 17:48:27 -0800
> | Subject: [Audacity-quality] Bug 243 – Default EQCurves.xml should be
> | populated and added to Windows and Mac installers
>> Is this bug resolved? I fixed it on Windows, and I think Peter resolved
>> it for Mac. Linux gets it in tarball?
> Not resolved, because needs more testing and deciding what priority
> to give to any remaining issues. I don't think the issue of where to
> place EQCurves.xml on Linux after compilation and installation of
> Audacity has received any discussion yet by a Linux developer.
Thanks. Cc-ing -devel. And more below for -devel.
> I assume by "Peter" you mean Paul Livesey, as per this thread:
I guess that's a case of "robbing Paul to credit Peter"?! :-)
> Clearly Bill has highlighted Mac-specific issues with EQCurves.xml
> in this -quality list thread:
Yes, I saw that, but I thought he later resolved all those questions. If
not, somebody (Bill or you, probably) please summarize and comment to
> e.g. Audacity does not seem to be looking in the application dir for
> EQCurves.xml. The issue can't be considered properly for Mac until
> it can be tested in the Mac Nightly Build. I'm including EQCurves.xml
> in the Win "Nightlies".
-devel, please comment.
> More generally, I'm not convinced what happens for user when they
> upgrade from 1.3.12 to 1.3.13 (or start as a new user with 1.3.13)
> and come across EQCurves.xml is an easy-to-understand experience.
It's a beta.
> One reason I haven't moved this issue along is because I want to test
> this properly. As an example, if EQCurves.xml in the app dir is
> read-only in usage, why allow Audacity to overwrite it?
> Personally I think it highly confusing to have two files with the same
> name in the app dir and the data dir, ...
Users should never (99%) be aware of it.
>...but I'm not going to say any more
> until I can test it and see if any detail improvements can be made to
> the current implementation. I understand the expediency of not
> writing and testing more code, but what we have now seems clunky
> and non-trivial to test to me. Yes, not building the curves in allows
> "easy updates to the defaults, without a re-compile", but that isn't
> really a user benefit.
I think it is. We can supply tiny installers that just update the
> Finally (although possibly not now P2), issues with what exact curves
> to include and their properties isn't finalised IMO. Bill has issues I
> think with the Treble/Bass Cut/Boost which I believe he will post to:
> and I'm not convinced we should have no 78 rpm curves at all. There
> is definitely a problem that to be useful, there probably needs to be
> at least three 78 rpm curves, but I don't think that's an excessive
Please come to a decision on this. We can always update it.
Let's get on to a *much* faster release cycle.