Re: [Audacity-quality] Bug 243 – Default EQCurves.xml should be populated and added to Windows and Mac installers

[Peter S. <pet...@ya...>]

Gale wrote:
>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 
>number.  

+1

Peter

 Peter Sampson
Tel: +44 (0)1625 524 780
Mob: +44 (0)7732 278 299 




________________________________
From: Gale Andrews <ga...@au...>
To: audacity-quality <aud...@li...>
Cc: aud...@li...
Sent: Wed, December 1, 2010 2:53:25 PM
Subject: Re: [Audacity-quality] Bug 243 – Default EQCurves.xml should be 
populated and added to Windows and Mac installers


| From Vaughan Johnson <va...@au...> 
| 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
> http://bugzilla.audacityteam.org/show_bug.cgi?id=243
> 
> 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.    

I assume by "Peter" you mean Paul Livesey, as per this thread:
http://audacity.238276.n2.nabble.com/Mac-build-td5640929.html

Clearly Bill has highlighted Mac-specific issues with EQCurves.xml 
in this -quality list thread:
http://tinyurl.com/2u253ho

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

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

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: 
http://wiki.audacityteam.org/wiki/Default_EQCurves

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





Gale 


------------------------------------------------------------------------------
Increase Visibility of Your 3D Game App & Earn a Chance To Win $500!
Tap into the largest installed PC base & get more eyes on your game by
optimizing for Intel(R) Graphics Technology. Get started today with the
Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs.
http://p.sf.net/sfu/intelisp-dev2dev
_______________________________________________
Audacity-quality mailing list
Aud...@li...
https://lists.sourceforge.net/lists/listinfo/audacity-quality