Thread: [Audacity-devel] Better EQ curves
A free multi-track audio editor and recorder
Brought to you by:
aosiniao
From: Martyn S. <mar...@go...> - 2010-03-12 01:43:06
|
Hi I have been working on getting some better EQ curves for the Equaliser and would like some feedback. The curve below is calculated from the equation for the RIAA EQ curves at 'conventional' 1/3rd octave points (I think/hope). It is ready to be pasted into your EQCurves.xml file, wherever that is (mine is currently in C:\Users\Martyn\AppData\Roaming\Audacity on win7). I could easily add more points for higher sampling rates (up to what?). Closer spacing seems pointless. The way it's set up at the moment all the built-in curves have to have the same frequency spacing (and I'm not inclined to change that aspect). I wanted to re-do all the in-built curves at the conventional frequency spacing, but don't find the equations for them. The best reference I have come across is http://home.clara.net/rfwilmut/repro78/repro.html#eq but most of those don't tie up with what we have (which I seem to remember Mitch telling me he got from 'some graphs' in 'a book'). Would there be any objection to reducing the number of built-in curves to just the ones that can be validated, whilst making others available on-line for pasting into EQCurves.xml as required? We could add/improve 'Telephone' and '100Hz Rumble Filter' that I see Steve and Koz have 'out there' at the same time. Feedback/ideas? Martyn PS also looking into getting the points to correspond to the grid exactly, which they currently don't. <curve name="RIAA Calculated"> <point f="20.000000000000" d="19.274000000000"/> <point f="25.000000000000" d="18.954000000000"/> <point f="31.000000000000" d="18.516000000000"/> <point f="40.000000000000" d="17.792000000000"/> <point f="50.000000000000" d="16.946000000000"/> <point f="63.000000000000" d="15.852000000000"/> <point f="80.000000000000" d="14.506000000000"/> <point f="100.000000000000" d="13.088000000000"/> <point f="125.000000000000" d="11.563000000000"/> <point f="160.000000000000" d="9.809000000000"/> <point f="200.000000000000" d="8.219000000000"/> <point f="250.000000000000" d="6.677000000000"/> <point f="315.000000000000" d="5.179000000000"/> <point f="400.000000000000" d="3.784000000000"/> <point f="500.000000000000" d="2.648000000000"/> <point f="630.000000000000" d="1.642000000000"/> <point f="800.000000000000" d="0.751000000000"/> <point f="1000.000000000000" d="0.000000000000"/> <point f="1250.000000000000" d="-0.744000000000"/> <point f="1600.000000000000" d="-1.643000000000"/> <point f="2000.000000000000" d="-2.589000000000"/> <point f="2500.000000000000" d="-3.700000000000"/> <point f="3150.000000000000" d="-5.038000000000"/> <point f="4000.000000000000" d="-6.605000000000"/> <point f="5000.000000000000" d="-8.210000000000"/> <point f="6300.000000000000" d="-9.980000000000"/> <point f="8000.000000000000" d="-11.894000000000"/> <point f="10000.000000000000" d="-13.734000000000"/> <point f="12500.000000000000" d="-15.609000000000"/> <point f="16000.000000000000" d="-17.708000000000"/> <point f="20000.000000000000" d="-19.620000000000"/> <point f="22050.000000000000" d="-20.460000000000"/> </curve> |
From: Stevethefiddle <ste...@gm...> - 2010-03-12 17:10:55
|
It looks good and it works. I'm not an expert in RIAA, but is it really worth going down to 20Hz/19.274dB when the "audio" at 20Hz is likely to just be turntable rumble and disk warp? Wasn't the RIAA standard updated/enhanced with a curve in which the very low frequency boost dropped lower? Martyn Shaw-2 wrote: > > Would there be any objection to reducing the number of built-in curves > to just the ones that can be validated, whilst making others available > on-line for pasting into EQCurves.xml as required? We could > add/improve 'Telephone' and '100Hz Rumble Filter' that I see Steve and > Koz have 'out there' at the same time. > > Feedback/ideas? > I would personally be in favour of reducing the number of RIAA type curves that are included by default and adding a few "general purpose" settings. Have a few settings such as "bass boost/bass cut/treble boost/treble cut/telephone/loudness/rumble filter" would not only be useful to a wider audience but would in my opinion have "educational value" for people that are new to audio processing. Koz and myself have also put forward the idea of a simple user interface for importing/exporting curve data. I don't think that anyone has taken up this idea yet, but even if there was just simple buttons to "Export This Curve"/"Import Curve" (and any invalid XML files just rejected with an error message) it would tie in well with your suggestion. There is a brief mention of this idea http://wiki.audacityteam.org/wiki/Feature_Requests Steve -- View this message in context: http://n2.nabble.com/Better-EQ-curves-tp4719919p4723257.html Sent from the audacity-devel mailing list archive at Nabble.com. |
From: Richard A. <ri...@au...> - 2010-03-12 20:39:44
|
On Fri, 2010-03-12 at 09:10 -0800, Stevethefiddle wrote: > I'm not an expert in RIAA, but is it really worth going down to > 20Hz/19.274dB when the "audio" at 20Hz is likely to just be turntable rumble > and disk warp? Wasn't the RIAA standard updated/enhanced with a curve in > which the very low frequency boost dropped lower? RIAA curve didn't change, but the IEC produced their own derivative version with the additional low cut, but the turn-over for this is 7950µs (20.02Hz), so it's only going to take effect if we lower the LF end a fair amount more. There is also pretty good evidence that the playback-only cut (which is what it is) is neither particularly useful (because it's not steep enough) or very important (because most material won't sound significantly different with the very bottom moved by 5dB on most systems). You can also get into the argument about the extra HF constant (it has to exist, because you can't boost the signal level with frequency indefinitely, and seems to be about 3.18us / 50kHz), but come to much the same conclusions. My view would be that a mechanism for providing the correct phase response, whilst much harder, will probably be much more important in terms of quality. This essentially means that as well as the frequency response (real part of the curve) we need to calculate, input, store etc the phase response (imaginary part of the curve). You probably won't find the information on what the phase response is on the web as much, but it's easy enough to work out from the specified turnover frequencies (3180, 318, 75 us) and the fact that the record amplifiers are all 1st order R-C analogue filters. Or we can cheat, simulate the circuit with ideal components and pick the phase values off the simulation output plot at the frequencies we want. Richard |
From: Martyn S. <mar...@go...> - 2010-03-15 00:02:23
|
On 12/03/2010 17:10, Stevethefiddle wrote: > > It looks good and it works. Thanks. > I'm not an expert in RIAA, but is it really worth going down to > 20Hz/19.274dB when the "audio" at 20Hz is likely to just be turntable rumble > and disk warp? Wasn't the RIAA standard updated/enhanced with a curve in > which the very low frequency boost dropped lower? Will respond to Richard on that. > Martyn Shaw-2 wrote: >> >> Would there be any objection to reducing the number of built-in curves >> to just the ones that can be validated, whilst making others available >> on-line for pasting into EQCurves.xml as required? We could >> add/improve 'Telephone' and '100Hz Rumble Filter' that I see Steve and >> Koz have 'out there' at the same time. >> >> Feedback/ideas? >> > > I would personally be in favour of reducing the number of RIAA type curves > that are included by default and adding a few "general purpose" settings. > Have a few settings such as "bass boost/bass cut/treble boost/treble > cut/telephone/loudness/rumble filter" would not only be useful to a wider > audience but would in my opinion have "educational value" for people that > are new to audio processing. That sounds good to me. We wouldn't want the full '1/3rd octave' freq points for these as it would be an inconvenience to the user. Do you have particular curves in mind? Examples? Break points? To do this well would mean including freq/dB pairs in the code for each curve, something we don't do at the moment but should be within reach. We should be able to turn xml versions into code (with a little effort) that then gets output as the default xml file. > Koz and myself have also put forward the idea of a simple user interface for > importing/exporting curve data. I don't think that anyone has taken up this > idea yet, but even if there was just simple buttons to "Export This > Curve"/"Import Curve" (and any invalid XML files just rejected with an error > message) it would tie in well with your suggestion. There is a brief mention > of this idea http://wiki.audacityteam.org/wiki/Feature_Requests A quick glance doesn't find that on that page. Do you want to work up a fuller version somewhere? It seems like a good idea and I would like users to be able to exchange curves easily like this. TTFN Martyn > Steve > |
From: Stevethefiddle <ste...@gm...> - 2010-03-16 19:25:30
|
I've written up a proposal on the Audacity wiki: http://wiki.audacityteam.org/wiki/Proposal_Import/Export_Eq_Curves Steve Martyn Shaw-2 [via Audacity] wrote: > > > On 12/03/2010 17:10, Stevethefiddle wrote: > > > > It looks good and it works. > > Thanks. > > > I'm not an expert in RIAA, but is it really worth going down to > > 20Hz/19.274dB when the "audio" at 20Hz is likely to just be > turntable rumble > > and disk warp? Wasn't the RIAA standard updated/enhanced with a > curve in > > which the very low frequency boost dropped lower? > > Will respond to Richard on that. > > > Martyn Shaw-2 wrote: > >> > >> Would there be any objection to reducing the number of built-in curves > >> to just the ones that can be validated, whilst making others available > >> on-line for pasting into EQCurves.xml as required? We could > >> add/improve 'Telephone' and '100Hz Rumble Filter' that I see Steve and > >> Koz have 'out there' at the same time. > >> > >> Feedback/ideas? > >> > > > > I would personally be in favour of reducing the number of RIAA type > curves > > that are included by default and adding a few "general purpose" > settings. > > Have a few settings such as "bass boost/bass cut/treble boost/treble > > cut/telephone/loudness/rumble filter" would not only be useful to a > wider > > audience but would in my opinion have "educational value" for people > that > > are new to audio processing. > > That sounds good to me. We wouldn't want the full '1/3rd octave' freq > points for these as it would be an inconvenience to the user. Do you > have particular curves in mind? Examples? Break points? > > To do this well would mean including freq/dB pairs in the code for > each curve, something we don't do at the moment but should be within > reach. We should be able to turn xml versions into code (with a > little effort) that then gets output as the default xml file. > > > Koz and myself have also put forward the idea of a simple user > interface for > > importing/exporting curve data. I don't think that anyone has taken > up this > > idea yet, but even if there was just simple buttons to "Export This > > Curve"/"Import Curve" (and any invalid XML files just rejected with > an error > > message) it would tie in well with your suggestion. There is a brief > mention > > of this idea http://wiki.audacityteam.org/wiki/Feature_Requests > > A quick glance doesn't find that on that page. Do you want to work up > a fuller version somewhere? It seems like a good idea and I would > like users to be able to exchange curves easily like this. > > TTFN > Martyn > > > Steve -- View this message in context: http://n2.nabble.com/Better-EQ-curves-tp4719919p4745867.html Sent from the audacity-devel mailing list archive at Nabble.com. |
From: Martyn S. <mar...@go...> - 2010-06-09 00:25:52
|
Hi Steve, and others I've been slowly working on the EQ curves loading/saving problem and have come up with this http://dl.dropbox.com/u/1327769/Audacity.exe . It's an .exe to replace the one in whatever release build you have, not a full installer, so 'not all there'. Any chance of you having a quick test? I have almost followed "Martyn: So here's an idea:" on http://wiki.audacityteam.org/wiki/Proposal_Import/Export_Eq_Curves where I tried to follow what I thought we both wanted. There are variations as I went along, but I have tried to follow the principles. There are no longer 'default' curves in the exe but there 'should' be a default EQCurves.xml in the same directory as the .exe file (you won't have that, unless you do it yourself). If you delete/rename EQCurves.xml in C:\Users\You\AppData\Roaming\Audacity (or wherever that is for you) then it should pick up the file with the .exe or take you to a web page. With the new dialog you should be able to: Import curves to your list from a properly formatted xml file. Export the selected curves to a properly formatted xml file. Move curves up/down the list (one at a time for now) (with buttons). Delete curves from your list (multiple selection) (delete key or a button). Should it say 'delete 17 items' and do them all? Or behave as it does now? Rename selected curves ('enter', double-click or a button). Please have an explore. Any feedback would be appreciated. This is hard to put into the codebase as it's a bit all-or-nothing. We need a decent default set of curves. Do you have any that we can add to the set? Thanks Martyn On 16/03/2010 19:25, Stevethefiddle wrote: > I've written up a proposal on the Audacity wiki: > http://wiki.audacityteam.org/wiki/Proposal_Import/Export_Eq_Curves > > Steve ... |
From: David B. <drb...@go...> - 2010-06-16 16:17:04
|
Hi Martyn, I've had a quick look at the changes to the equalization dialog (thanks Gale for the recent build). A couple of comments about the new manage curves dialog: 1. I think that if the focus is in the list and a user presses enter they would expect the the ok button to be pressed, rather than the rename dialog to open. (see for example the choose details dialog on the view menu in windows explorer). Is there a reason for it being like this? 2.In the rename dialog, Jaws and nvda don't read the text above the text box. A common way of setting out rename is to put the existing name as selected text in the edit box - this would also ensure that screen readers read it. Another strangeness which I'm not sure why happens, and you might not be able to fix at the moment is that when the manage curves dialog is opened, Jaws reads the text at the top of the equalization dialog before starting to read the manage curves dialog, and a similar effect occurs when I open the rename dialog, only this time it's the help text at the bottom of the manage curves dialog. Finally there remain some significant accessibility problems in the equalization dialog: for example the labels of the pair of radio buttons are not read (draw curves and graphic eq). David. |
From: Martyn S. <mar...@go...> - 2010-03-25 02:00:56
|
Thanks Steve, I have written up another one, taking into account various contributors. What do you think? Too complicated? Martyn On 16/03/2010 19:25, Stevethefiddle wrote: > I've written up a proposal on the Audacity wiki: > http://wiki.audacityteam.org/wiki/Proposal_Import/Export_Eq_Curves > > Steve > > > > Martyn Shaw-2 [via Audacity] wrote: > > > > > > > On 12/03/2010 17:10, Stevethefiddle wrote: > > > > > > It looks good and it works. > > > > Thanks. > > > > > I'm not an expert in RIAA, but is it really worth going down to > > > 20Hz/19.274dB when the "audio" at 20Hz is likely to just be > > turntable rumble > > > and disk warp? Wasn't the RIAA standard updated/enhanced with a > > curve in > > > which the very low frequency boost dropped lower? > > > > Will respond to Richard on that. > > > > > Martyn Shaw-2 wrote: > > >> > > >> Would there be any objection to reducing the number of built-in > curves > > >> to just the ones that can be validated, whilst making others > available > > >> on-line for pasting into EQCurves.xml as required? We could > > >> add/improve 'Telephone' and '100Hz Rumble Filter' that I see Steve > and > > >> Koz have 'out there' at the same time. > > >> > > >> Feedback/ideas? > > >> > > > > > > I would personally be in favour of reducing the number of RIAA type > > curves > > > that are included by default and adding a few "general purpose" > > settings. > > > Have a few settings such as "bass boost/bass cut/treble boost/treble > > > cut/telephone/loudness/rumble filter" would not only be useful to a > > wider > > > audience but would in my opinion have "educational value" for people > > that > > > are new to audio processing. > > > > That sounds good to me. We wouldn't want the full '1/3rd octave' freq > > points for these as it would be an inconvenience to the user. Do you > > have particular curves in mind? Examples? Break points? > > > > To do this well would mean including freq/dB pairs in the code for > > each curve, something we don't do at the moment but should be within > > reach. We should be able to turn xml versions into code (with a > > little effort) that then gets output as the default xml file. > > > > > Koz and myself have also put forward the idea of a simple user > > interface for > > > importing/exporting curve data. I don't think that anyone has taken > > up this > > > idea yet, but even if there was just simple buttons to "Export This > > > Curve"/"Import Curve" (and any invalid XML files just rejected with > > an error > > > message) it would tie in well with your suggestion. There is a brief > > mention > > > of this idea http://wiki.audacityteam.org/wiki/Feature_Requests > > > > A quick glance doesn't find that on that page. Do you want to work up > > a fuller version somewhere? It seems like a good idea and I would > > like users to be able to exchange curves easily like this. > > > > TTFN > > Martyn > > > > > Steve > > > ------------------------------------------------------------------------ > View this message in context: Re: Better EQ curves > <http://n2.nabble.com/Better-EQ-curves-tp4719919p4745867.html> > Sent from the audacity-devel mailing list archive > <http://n2.nabble.com/audacity-devel-f238278.html> at Nabble.com. > > > > ------------------------------------------------------------------------------ > Download Intel® Parallel Studio Eval > Try the new software tools for yourself. Speed compiling, find bugs > proactively, and fine-tune applications for parallel performance. > See why Intel Parallel Studio got high marks during beta. > http://p.sf.net/sfu/intel-sw-dev > > > > _______________________________________________ > audacity-devel mailing list > aud...@li... > https://lists.sourceforge.net/lists/listinfo/audacity-devel |
From: Martyn S. <mar...@go...> - 2010-05-14 00:03:59
Attachments:
EQ.diff
|
Hi there Just to let you know that this is on my agenda, and that I'm still here, although less active than I was. I had a look at what we'd all written here and at at http://wiki.audacityteam.org/wiki/Proposal_Import/Export_Eq_Curves and have got some way with it. Attached patch only has the first 4 buttons doing anything at the moment, and may not work for all, but I thought I'd ask for feedback on what I have so far. TTFN Martyn On 25/03/2010 02:00, Martyn Shaw wrote: > Thanks Steve, I have written up another one, taking into account various > contributors. What do you think? Too complicated? > > Martyn > > On 16/03/2010 19:25, Stevethefiddle wrote: >> I've written up a proposal on the Audacity wiki: >> http://wiki.audacityteam.org/wiki/Proposal_Import/Export_Eq_Curves >> >> Steve >> >> >> >> Martyn Shaw-2 [via Audacity] wrote: >> >> > >> > >> > On 12/03/2010 17:10, Stevethefiddle wrote: >> > > >> > > It looks good and it works. >> > >> > Thanks. >> > >> > > I'm not an expert in RIAA, but is it really worth going down to >> > > 20Hz/19.274dB when the "audio" at 20Hz is likely to just be >> > turntable rumble >> > > and disk warp? Wasn't the RIAA standard updated/enhanced with a >> > curve in >> > > which the very low frequency boost dropped lower? >> > >> > Will respond to Richard on that. >> > >> > > Martyn Shaw-2 wrote: >> > >> >> > >> Would there be any objection to reducing the number of built-in >> curves >> > >> to just the ones that can be validated, whilst making others >> available >> > >> on-line for pasting into EQCurves.xml as required? We could >> > >> add/improve 'Telephone' and '100Hz Rumble Filter' that I see Steve >> and >> > >> Koz have 'out there' at the same time. >> > >> >> > >> Feedback/ideas? >> > >> >> > > >> > > I would personally be in favour of reducing the number of RIAA type >> > curves >> > > that are included by default and adding a few "general purpose" >> > settings. >> > > Have a few settings such as "bass boost/bass cut/treble boost/treble >> > > cut/telephone/loudness/rumble filter" would not only be useful to a >> > wider >> > > audience but would in my opinion have "educational value" for people >> > that >> > > are new to audio processing. >> > >> > That sounds good to me. We wouldn't want the full '1/3rd octave' freq >> > points for these as it would be an inconvenience to the user. Do you >> > have particular curves in mind? Examples? Break points? >> > >> > To do this well would mean including freq/dB pairs in the code for >> > each curve, something we don't do at the moment but should be within >> > reach. We should be able to turn xml versions into code (with a >> > little effort) that then gets output as the default xml file. >> > >> > > Koz and myself have also put forward the idea of a simple user >> > interface for >> > > importing/exporting curve data. I don't think that anyone has taken >> > up this >> > > idea yet, but even if there was just simple buttons to "Export This >> > > Curve"/"Import Curve" (and any invalid XML files just rejected with >> > an error >> > > message) it would tie in well with your suggestion. There is a brief >> > mention >> > > of this idea http://wiki.audacityteam.org/wiki/Feature_Requests >> > >> > A quick glance doesn't find that on that page. Do you want to work up >> > a fuller version somewhere? It seems like a good idea and I would >> > like users to be able to exchange curves easily like this. >> > >> > TTFN >> > Martyn >> > >> > > Steve >> >> >> ------------------------------------------------------------------------ >> View this message in context: Re: Better EQ curves >> <http://n2.nabble.com/Better-EQ-curves-tp4719919p4745867.html> >> Sent from the audacity-devel mailing list archive >> <http://n2.nabble.com/audacity-devel-f238278.html> at Nabble.com. >> >> >> >> ------------------------------------------------------------------------------ >> >> Download Intel® Parallel Studio Eval >> Try the new software tools for yourself. Speed compiling, find bugs >> proactively, and fine-tune applications for parallel performance. >> See why Intel Parallel Studio got high marks during beta. >> http://p.sf.net/sfu/intel-sw-dev >> >> >> >> _______________________________________________ >> audacity-devel mailing list >> aud...@li... >> https://lists.sourceforge.net/lists/listinfo/audacity-devel |
From: Stevethefiddle <ste...@gm...> - 2010-06-09 18:09:25
|
I've tested all of the buttons and everything appears to work as expected, but I've not been able to test the "Help" button (no Internet connection on my Windows PC). Handling of bad tags/tokens in the XML file seems to pretty good, though I've not tested that very extensively. "Should it say 'delete 17 items' and do them all?" Personally I'd prefer that option, but the current behaviour is much safer. Perhaps a compromise solution would be to not require individual confirmation for each curve, but to ask if the user wants to export a backup before deleting (default value = yes, make a backup). The only things that struck me as not being intuitively obvious are: 1) saving a new (custom) curve is achieved by renaming the "custom" curve. 2) exporting the custom curve exports a file with no data (could this be changed to export the current curve - perhaps a prompt for a curve name?) 3) How to get at the (on-line) help. I realise that there's already a lot of buttons, but would a Help button on the main interface be useful? Do we have any provision for users to submit curves? Assuming that the help page actually exists, could you post the URL (I'm not able to access it from the interface as that does not work under WINE). Other than that this Eq Curves manager does just about everything I hoped for. Nice work, and thanks very much :=) Steve -- View this message in context: http://audacity.238276.n2.nabble.com/Better-EQ-curves-tp4719919p5159723.html Sent from the audacity-devel mailing list archive at Nabble.com. |
From: Martyn S. <mar...@go...> - 2010-06-09 22:51:11
|
Hi Steve Thanks for the feedback! On 09/06/2010 19:09, Stevethefiddle wrote: > > I've tested all of the buttons and everything appears to work as expected, Good! > but I've not been able to test the "Help" button (no Internet connection on > my Windows PC). That button is badly named and just opens a browser window to http://wiki.audacityteam.org/wiki/EQCurvesDownload (which needs some work). I could just make the button open the window and avoid the extra dialog - I'll get on that. > Handling of bad tags/tokens in the XML file seems to pretty good, though > I've not tested that very extensively. That uses the same library and code that was already there before. It will read curves with blank or duplicate names, but not allow you to create them. > "Should it say 'delete 17 items' and do them all?" > Personally I'd prefer that option, but the current behaviour is much safer. There is safety anyway since the curves are not actually written out to EQCurves.xml until you press the OK button on the Modify Curves dialog, you are only playing with a copy. > Perhaps a compromise solution would be to not require individual > confirmation for each curve, but to ask if the user wants to export a backup > before deleting (default value = yes, make a backup). It's a thought. I could copy the old EQCurves.xml to EQCurves.bak when you press the OK button so that the previous state was preserved. > The only things that struck me as not being intuitively obvious are: > > 1) saving a new (custom) curve is achieved by renaming the "custom" curve. Would renaming 'custom' help there? It's there from the previous version. Perhaps call it 'Modified' or something? What else could we do? > 2) exporting the custom curve exports a file with no data (could this be > changed to export the current curve - perhaps a prompt for a curve name?) That is broken and I'll fix it somehow. You can't Export 'custom' and I'd missed the case where it's the only one selected. > 3) How to get at the (on-line) help. I realise that there's already a lot of > buttons, but would a Help button on the main interface be useful? See above. > Do we have any provision for users to submit curves? Not yet. We probably don't want users to be able to upload curves directly somewhere for security reasons. I put 2 on my dropbox account for testing purposes but that isn't a long-term solution. My best idea yet is to treat them like we do translations and put them into the SVN. That way people could send them (with some text for the wiki) to us (people with commit privileges) for a basic sanity check and then we could upload them to a safe place and update the wiki. It shouldn't be a big load that I could do for now. What do you think? We need a set of default curves and at least one downloadable set before this can be released. http://wiki.audacityteam.org/wiki/Default_EQCurves > Assuming that the help page actually exists, could you post the URL (I'm not > able to access it from the interface as that does not work under WINE). http://wiki.audacityteam.org/wiki/EQCurvesDownload > Other than that this Eq Curves manager does just about everything I hoped > for. Nice work, and thanks very much :=) My pleasure! Martyn > Steve |
From: Gale A. <ga...@au...> - 2010-06-11 17:14:30
|
| From Martyn Shaw <mar...@go...> | Wed, 09 Jun 2010 23:50:48 +0100 | Subject: [Audacity-devel] Better EQ curves > - Delete curves from your list (multiple selection) (delete key or a > button). Should it say 'delete 17 items' and do them all? Or behave > as it does now? Making a backup as Steve suggested of EQCurves.xml to EQCurves.bak seems a bit like overkill to me - just another question you have to answer every time? Can the confirm message just list the proposed curves for deletion, and you either click "Yes" to delete 'em all, or "Cancel" to change your selection? >> (Steve) saving a new (custom) curve is achieved by renaming the >> "custom" curve. > Would renaming 'custom' help there? It's there from the previous version. > Perhaps call it 'Modified' or something? What else could we do? I think calling it "Unsaved" or "Modified" would be an improvement anyway. But if simply saving a modified curve is much more common than importing/exporting curves or changing the list order, don't we still want the Save button (or even the Delete too)? There are a lot of extra steps to Save now. Click the "Modify curves list..." button, then if you realise you can just hit ENTER that's easy, but unless you want to use the mouse, nine forward tabs are needed to get to OK so you can ENTER (or two backwards tabs). ESC after rename doesn't save the curve, but I guess that's OK/consistent. If we do put back the Save or Delete buttons, perhaps the "Modify curves list" should be "Manage curves list" or something suggesting that's more "advanced"? Some of the buttons in Modify Curves are missing access key underlines. > There are no longer 'default' curves in the exe. Will the finally committed changes allow the executable to recreate the default curves if they get accidentally deleted, as happens with current code? When I pressed the "Defaults" button it said EQCurves.xml was not found although it was there. I had deleted EQCurves.xml, run SVN Head to recreate it, then ran your .exe. Other things I noticed: * If I export a curve to an xml file, then reimport it, there are two curves in the list with the same name. Similarly if I do something stupid like import the default curve set twice, they are all duplicated. * If I rename a curve with its own name in error and accept the overwrite prompt, the curve is removed from the list * If I export a curve and choose the name of an existing curve, there is no overwrite warning. [That seems the case with Plot Spectrum export as well, but labels export has an overwrite warning.] > > Do we have any provision for users to submit curves? > > Not yet. We probably don't want users to be able to upload curves > directly somewhere for security reasons. I put 2 on my dropbox > account for testing purposes but that isn't a long-term solution. My > best idea yet is to treat them like we do translations and put them > into the SVN. That way people could send them (with some text for the > wiki) to us (people with commit privileges) for a basic sanity check and > then we could upload them to a safe place and update the wiki. Should people send the curves to you, to feedback@ or where? I think there may be a case for the default curve being in SVN, but I'm not sure we want to load SVN with user's curves? I think the Wiki would be better as a repository of those. I don't see any evidence from searching Google that XML is regarded as an upload threat for MediaWiki, though I'm no expert about that. Supposing the files were uploaded as .txt to Wiki and people just had to rename to .xml (or add the .xml extension) for use in Audacity. Is that a threat? Or what if the xml was zipped? No-one worries too much about the extra step of unzipping Nyquist files. Thanks, Gale |
From: Stevethefiddle <ste...@gm...> - 2010-06-13 20:18:53
|
I think the wiki would be a good place to keep a "library" of submitted Eq curves that were considered likely to be of interest/use to other users. One the manager is available in at least a nightly version we could start a topic on the forum inviting users to submit curves for inclusion in the wiki. -- View this message in context: http://audacity.238276.n2.nabble.com/Better-EQ-curves-tp4719919p5175216.html Sent from the audacity-devel mailing list archive at Nabble.com. |
From: Martyn S. <mar...@go...> - 2010-06-13 23:46:37
|
Agreed, and a good plan. How do we put an xml file on the wiki? We already have a page for suggesting curves for the default curves that will be committed to SVN and installed with the other stuff - please feel free to contribute http://wiki.audacityteam.org/wiki/Default_EQCurves We also have a place to link "library" files - please also feel free to modify and add to http://wiki.audacityteam.org/wiki/EQCurvesDownload TTFN Martyn On 13/06/2010 21:18, Stevethefiddle wrote: > > I think the wiki would be a good place to keep a "library" of submitted Eq > curves that were considered likely to be of interest/use to other users. One > the manager is available in at least a nightly version we could start a > topic on the forum inviting users to submit curves for inclusion in the > wiki. |
From: Martyn S. <mar...@go...> - 2010-06-13 23:51:55
|
All my todo items are ticked off here (inc. a warning on Export for overwriting files and renaming 'custom' as 'unnamed'). Since nobody has suggested otherwise I will try and commit the code to SVN tomorrow (I prefer to do that at the start of the time I have available, rather than the end). TTFN Martyn |
From: Gale A. <ga...@au...> - 2010-06-14 07:06:24
|
> Since nobody has suggested otherwise I will try and commit the code to > SVN tomorrow Didn't have time to throw my 2p's in until now but please see below .. | From Martyn Shaw <mar...@go...> | Sun, 13 Jun 2010 01:31:51 +0100 | Subject: [Audacity-devel] Better EQ curves > On 11/06/2010 18:14, Gale Andrews wrote: > > > > | From Martyn Shaw<mar...@go...> > > | Wed, 09 Jun 2010 23:50:48 +0100 > > | Subject: [Audacity-devel] Better EQ curves > >> - Delete curves from your list (multiple selection) (delete key or a > >> button). Should it say 'delete 17 items' and do them all? Or behave > >> as it does now? > > > > Making a backup as Steve suggested of EQCurves.xml to EQCurves.bak > > seems a bit like overkill to me - just another question you have to answer > > every time? > > I am now creating a file called EQBackup.xml in the same place as > EQCurves.xml. Then you can reload it with 'Import' if you went wrong. > Seems like a good compromise with no extra prompts. Good, as there are no prompts. I see "Import" defaults into the Audacity application data folder. Given we want to make it easy for users to import/export curves, is it worth defaulting it to the Audacity installation folder instead on Windows? Apart from the default curve also being there, the appdata folder is hidden by default. I notice if <curve name=""> is removed from the first curve in EQCurves.xml, Audacity freezes on Windows 7 and has to be force quit. Should we have a "mismatched" check on that as we do for non-default files? > >>> (Steve) saving a new (custom) curve is achieved by renaming the > >>> "custom" curve. > >> Would renaming 'custom' help there? It's there from the previous version. > >> Perhaps call it 'Modified' or something? What else could we do? > > > > I think calling it "Unsaved" or "Modified" would be an improvement > > anyway. > > Any other input anybody? "un-named" was also suggested. I was going to suggest "temporary" before I see you've decided on "un-named" - a) you can import a curve that has no (empty) name; b) your error message if you delete "custom" calls it "temporary" c) it may encourage saving ... but whatever. > But if simply saving a modified curve is much more common > > than importing/exporting curves or changing the list order, don't we > > still want the Save button (or even the Delete too)? > > Not really, there isn't space on smaller screens. Part of the idea > here is to save space. > > > There are a lot of extra steps to Save now... > Or SHIFT+ENTER? Not so many strokes. That's handy :=) but I wonder how many people know that - I didn't. I'm still not sure saving an unsaved curve by renaming, after clicking on a "Manage Curves list..." button, is all that intuitive. The Wiki proposal suggests that button could be called "Save/Modify list". I think including the "Save" word would help. Even so we can't have a "Save" button in the "Manage Curves" dialogue, so I still think a separate Save button is one-step and has no ambiguities. If it said "Save" and the other button said "Manage..." or "Presets...", there is enough space. But perhaps we may need the space later for something more interesting? > > Some of the buttons in Modify Curves are missing access key > > underlines. > > Sorted. We may wish to consider them further. I thought "D&elete" was better than "De&lete" (better to avoid underlined "l" if you can, as it's hard to see). So I changed that (which means "&Export" changes to "E&xport). Also took the opportunity to add the missing access keys for the main EQ interface. Attached, to do with as you wish (those are the only changes to your "Sun, 13 Jun 2010 01:31:51" patch). > I had deleted EQCurves.xml, run SVN Head to > > recreate it, then ran your .exe. > > > > Other things I noticed: > > > > * If I export a curve to an xml file, then reimport it, there are two > > curves in the list with the same name. > > Good. No loss of data (and a 'Delete' button that works on multiple > selections). We allow importing from files that have duplicate/blank > names (but not saving/allowing duplicate/blank names via 'Rename'). > Users can share XML files/curves: "try this XYZ curve instead of > yours" (user imports) "Ah yes, I imported yours and it's better, I've > compared them and renamed mine as 'poo'" I notice this isn't what the Wiki Proposal suggested: "If a curve import was attempted with a name already taken, obviously we would insist on a re-name / replace". I appreciate you can rename the duplicates after import, but if you don't do that at once it can get very hard to figure which curve is which. Can we date stamp them, or do an incremental rename like "amradio(1)", "amradio(2)"... ? I for one would find that heaps better. Gale |
From: Martyn S. <mar...@go...> - 2010-06-15 23:41:17
|
On 14/06/2010 08:06, Gale Andrews wrote: ... > I see "Import" defaults into the Audacity application data folder. Given > we want to make it easy for users to import/export curves, is it worth > defaulting it to the Audacity installation folder instead on Windows? > Apart from the default curve also being there, the appdata folder is > hidden by default. I picked that one (without too much thought) as the 'main' Audacity folder for user data, so a good place to store their user data. For example 'chains' are stored there (in a sub-directory). We could easily create a sub-directory for EQcurves as well, but that's another thought. The installation folder does not seem like a good place to direct people to as it has the files that we don't want them to delete or generally muck with. > I notice if<curve name=""> is removed from the first curve in > EQCurves.xml, Audacity freezes on Windows 7 and has to be force quit. > Should we have a "mismatched" check on that as we do for non-default > files? I see this but don't understand why it happens. I'll put it on my todo list but note that there is no way to cause this via the interface (is there?). Low priority. >>>>> (Steve) saving a new (custom) curve is achieved by renaming the >>>>> "custom" curve. >>>> Would renaming 'custom' help there? It's there from the previous version. >>>> Perhaps call it 'Modified' or something? What else could we do? >>> >>> I think calling it "Unsaved" or "Modified" would be an improvement >>> anyway. >> >> Any other input anybody? "un-named" was also suggested. > > I was going to suggest "temporary" before I see you've decided on > "un-named" - I see no better ideas. 'Decided on' is not 'fixated on'. a) you can import a curve that has no (empty) name; > b) your error message if you delete "custom" calls it "temporary" > c) it may encourage saving ... but whatever. > > >> But if simply saving a modified curve is much more common >>> than importing/exporting curves or changing the list order, don't we >>> still want the Save button (or even the Delete too)? >> >> Not really, there isn't space on smaller screens. Part of the idea >> here is to save space. >> >>> There are a lot of extra steps to Save now... >> Or SHIFT+ENTER? Not so many strokes. > > That's handy :=) but I wonder how many people know that - I didn't. Neither did I until just before I wrote that! Education for keyboard users? > I'm still not sure saving an unsaved curve by renaming, after clicking on > a "Manage Curves list..." button, is all that intuitive. The Wiki proposal > suggests that button could be called "Save/Modify list". I think including > the "Save" word would help. OK, 'Save/Manage curves...' is what I'm committing. ... >>> Some of the buttons in Modify Curves are missing access key >>> underlines. >> >> Sorted. We may wish to consider them further. > > I thought "D&elete" was better than "De&lete" (better to avoid > underlined "l" if you can, as it's hard to see). So I changed that > (which means "&Export" changes to "E&xport). That's a good idea, I was struggling to avoid an "l". > Also took the opportunity to add the missing access keys for the main > EQ interface. Attached, to do with as you wish (those are the only > changes to your "Sun, 13 Jun 2010 01:31:51" patch). I see no attachment. >> I had deleted EQCurves.xml, run SVN Head to >>> recreate it, then ran your .exe. >>> >>> Other things I noticed: >>> >>> * If I export a curve to an xml file, then reimport it, there are two >>> curves in the list with the same name. >> >> Good. No loss of data (and a 'Delete' button that works on multiple >> selections). We allow importing from files that have duplicate/blank >> names (but not saving/allowing duplicate/blank names via 'Rename'). >> Users can share XML files/curves: "try this XYZ curve instead of >> yours" (user imports) "Ah yes, I imported yours and it's better, I've >> compared them and renamed mine as 'poo'" > > I notice this isn't what the Wiki Proposal suggested: > > "If a curve import was attempted with a name already taken, > obviously we would insist on a re-name / replace". I changed my mind on that. > I appreciate you can rename the duplicates after import, but if you > don't do that at once it can get very hard to figure which curve is > which. Can we date stamp them, or do an incremental rename > like "amradio(1)", "amradio(2)"... ? I for one would find that heaps > better. That would be possible, but work to do (and you have suggested a scheme). I'll add it to my todo list, which is paper-based and occasionally gets recycled by others in my household. I'm guessing by the minutia that you are fining this basically OK. TTFN Martyn > Gale > > ------------------------------------------------------------------------------ > ThinkGeek and WIRED's GeekDad team up for the Ultimate > GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the > lucky parental unit. See the prize list and enter to win: > http://p.sf.net/sfu/thinkgeek-promo > _______________________________________________ > audacity-devel mailing list > aud...@li... > https://lists.sourceforge.net/lists/listinfo/audacity-devel > |
From: David B. <drb...@go...> - 2010-06-16 07:48:27
|
On Wed, Jun 16, 2010 at 12:41 AM, Martyn Shaw <mar...@go...> wrote: > >>> >>>> There are a lot of extra steps to Save now... >>> Or SHIFT+ENTER? Not so many strokes. >> >> That's handy :=) but I wonder how many people know that - I didn't. > > Neither did I until just before I wrote that! Education for keyboard > users? As far as I can see, the mods to the dialog aren't currently in Gale's nightly build, so I haven't seen the modified dialog. However, Gale has said that you can get to the ok button by pressing shift+tab twice, and this sounds workable to me. I don't think that introducing non-standard keystrokes is a useful way to go. David. |
From: Gale A. <ga...@au...> - 2010-06-16 09:00:57
|
| From David Bailes <drb...@go...> | Wed, 16 Jun 2010 08:48:20 +0100 | Subject: [Audacity-devel] Better EQ curves > On Wed, Jun 16, 2010 at 12:41 AM, Martyn Shaw > <mar...@go...> wrote: > >>> > >>>> There are a lot of extra steps to Save now... > >>> Or SHIFT+ENTER? Not so many strokes. > >> > >> That's handy :=) but I wonder how many people know that - I didn't. > > > > Neither did I until just before I wrote that! Education for keyboard > > users? > > As far as I can see, the mods to the dialog aren't currently in Gale's > nightly build, so I haven't seen the modified dialog. Martyn's only just committed the changes, but you can see the new "Manage Curves" dialog if you update now from the usual place: http://www.gaclrecords.org.uk/audacity.html Martyn committed my suggested change to the access keys for the new dialogue (thanks). My patch for access keys in the EQ window itself did seem to have dropped out of my other e-mail, sorry. I'll commit that separately a bit later, then that will be in the next "nightly" after the one I've just uploaded. > However, Gale has said that you can get to the ok button by pressing > shift+tab twice, and this sounds workable to me. I don't think that > introducing non-standard keystrokes is a useful way to go. SHIFT + ENTER doesn't work in all dialogues anyway e.g. after having browsed for LAME or FFmpeg in Preferences, it doesn't let you get straight to "OK" rather than hitting "Browse" again. Gale |
From: Martyn S. <mar...@go...> - 2010-06-16 21:29:16
|
Hi David On 16/06/2010 08:48, David Bailes wrote: > On Wed, Jun 16, 2010 at 12:41 AM, Martyn Shaw > <mar...@go...> wrote: >> > >>>> >>>>> There are a lot of extra steps to Save now... >>>> Or SHIFT+ENTER? Not so many strokes. >>> >>> That's handy :=) but I wonder how many people know that - I didn't. >> >> Neither did I until just before I wrote that! Education for keyboard >> users? > > As far as I can see, the mods to the dialog aren't currently in Gale's > nightly build, so I haven't seen the modified dialog. However, Gale > has said that you can get to the ok button by pressing shift+tab > twice, and this sounds workable to me. I don't think that introducing > non-standard keystrokes is a useful way to go. I didn't introduce that SHIFT+ENTER on purpose, it was just there! TTFN Martyn > David. > > ------------------------------------------------------------------------------ > ThinkGeek and WIRED's GeekDad team up for the Ultimate > GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the > lucky parental unit. See the prize list and enter to win: > http://p.sf.net/sfu/thinkgeek-promo > _______________________________________________ > audacity-devel mailing list > aud...@li... > https://lists.sourceforge.net/lists/listinfo/audacity-devel > |
From: Martyn S. <mar...@go...> - 2010-06-16 00:09:36
|
On 14/06/2010 08:06, Gale Andrews wrote: ... > I notice if<curve name=""> is removed from the first curve in > EQCurves.xml, Audacity freezes on Windows 7 and has to be force quit. I notice that that goes back to 1.3.2. Maybe a library problem? Martyn > Gale > > ------------------------------------------------------------------------------ > ThinkGeek and WIRED's GeekDad team up for the Ultimate > GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the > lucky parental unit. See the prize list and enter to win: > http://p.sf.net/sfu/thinkgeek-promo > _______________________________________________ > audacity-devel mailing list > aud...@li... > https://lists.sourceforge.net/lists/listinfo/audacity-devel > |
From: David B. <drb...@go...> - 2010-06-19 13:16:31
|
On Thu, Jun 17, 2010 at 12:20 AM, Martyn Shaw <mar...@go...> wrote: > Hi David > > Thanks for the feedback! > > On 16/06/2010 17:16, David Bailes wrote: >> Hi Martyn, >> >> I've had a quick look at the changes to the equalization dialog >> (thanks Gale for the recent build). A couple of comments about the new >> manage curves dialog: >> 1. I think that if the focus is in the list and a user presses enter >> they would expect the the ok button to be pressed, rather than the >> rename dialog to open. (see for example the choose details dialog on >> the view menu in windows explorer). Is there a reason for it being >> like this? > > This is not by design, but a consequence of using > EVT_LIST_ITEM_ACTIVATED to detect double-left-clicks to rename, which > was requested by my son. Unfortunately EVT_LIST_ITEM_ACTIVATED > detects double-clicks AND 'Enter' and I currently can't see how to > differentiate the two. I will add that to the list of things to do. I'd be suprised if you can differentiate the two, and I'm not sure it would be desirable anyway - my understanding is that double click and enter are normally equivalent. I think that for the benifit of those who have to use keyboard navigation, the enter/double click should not rename. I don't think it's a big deal for mouse users is it? > >> 2.In the rename dialog, Jaws and nvda don't read the text above the >> text box. A common way of setting out rename is to put the existing >> name as selected text in the edit box - this would also ensure that >> screen readers read it. > > I had a quick look at this. I can put the text in the box but not > select it. Another one for the list. Just to clarify, this is only useful if you can put the text in the box and select it - text which isn't selected would be unhelpful, and it would be better to keep things as they are. > >> Finally there remain some significant accessibility problems in the >> equalization dialog: for example the labels of the pair of radio >> buttons are not read (draw curves and graphic eq). > > This is something I don't know much about. Are there similar dialogs > where it does work? Maybe I could see how the code differs. These are the controls whose labels aren't read by Jaws: - Draw curves/Graphic EQ radio buttons - Length of filter slider - Select curve drop down list box - when Draw curves is selected, the Linear frequency scale check box. As far as I'm aware, all the labels of all the controls in the preferences dialog are read ok by screen readers. eg on the Tracks page there are examples of check boxes and drop down list boxes, and on the Project page there's a group of radio buttons. David. |
From: Stevethefiddle <ste...@gm...> - 2010-06-23 23:20:47
|
A couple of problems on Linux (Ubuntu 9.04) XML files must have the extension ".XML" (upper case). ".xml" (lower case) is not seen by the Curves Manager. Immediately after exporting one or more curves, Audacity crashes (disappears). The curve is exported correctly, but Audacity immediately closes. If launched from a Terminal window it generates the error "Illegal instruction". Now the good news - we have started to get a few curves submitted on the forum. There's not many yet, but it's a start. http://forum.audacityteam.org/viewtopic.php?f=20&t=33824 Steve D -- View this message in context: http://audacity.238276.n2.nabble.com/Better-EQ-curves-tp4719919p5215621.html Sent from the audacity-devel mailing list archive at Nabble.com. |
From: Martyn S. <mar...@go...> - 2010-07-01 00:29:16
|
On 24/06/2010 00:20, Stevethefiddle wrote: > > A couple of problems on Linux (Ubuntu 9.04) > > XML files must have the extension ".XML" (upper case). > ".xml" (lower case) is not seen by the Curves Manager. Hopefully that is now fixed in SVN. > Immediately after exporting one or more curves, Audacity crashes > (disappears). The curve is exported correctly, but Audacity immediately > closes. If launched from a Terminal window it generates the error "Illegal > instruction". Have not got to that yet. TTFN Martyn > Now the good news - we have started to get a few curves submitted on the > forum. There's not many yet, but it's a start. > http://forum.audacityteam.org/viewtopic.php?f=20&t=33824 > > Steve D |
From: Stevethefiddle <ste...@gm...> - 2010-06-28 21:15:48
|
I've updated to the latest SVN and still have the same problems on Linux. Audacity 1.3.13-alpha-Jun 28 2010 (Unicode) 1) Audacity crashes on export of XML file. 2) Lower case .xml file extensions are not visible within the curve manager. -- View this message in context: http://audacity.238276.n2.nabble.com/Better-EQ-curves-tp4719919p5232694.html Sent from the audacity-devel mailing list archive at Nabble.com. |