Thanks Steve, that does it.
POL
On my system, 27 lines including empty lines separating paragraphs, but to allow for font variations and memorabilty, shall we settle on forced newlines at 50 characters, and 25 lines? It looks as if the real problem is that the Nyquist message boxes are much wider on Windows than Linux at high resolution, but to have a line 260 characters long and the next only a few characters long due to auto wordwrap doesn’t seem acceptable.
Gale
I agree, 50 characters x 25 lines looks much better, even if it means we can get less content per help screen.
If nothing else, it should encourage concise writing!
POL
50 characters x 25 lines looks OK here, but for complex plug-ins we could really do with a better solution - such as linking to a file in the plug-ins folder.
Here is version 2.3 of the 78EQCurveGen plug-in which, I hope, addresses the issues with previous versions.
Changes in this version include:
Reformating Help to a max of 50 characters and 25 lines per page.
The plug-in now determines the home directory from the OS, using the “get-env” function, and writes to that directory unless the user specifies differently.
Note: “get-env” seems to work reliably on all OSs, but it is only suported on later nightly builds, so using an earlier version of Audacity will generate an error message telling the user to input the file path manually. If the manually-entered file path doesn’t exist or isn’t writeable, an error message is also generated, explaining the problem.
These changes work on Windows, but need testing on Mac and Linux.
POL
78EQCurveGen20101028.ny (16.1 KB)
It appears to work OK on Linux (including the new Help screens).
Is there anything in particular that needs testing?
Output to “HOME directory” works correctly on Audacity 1.3.13 alpha and generates a sensible error message on Audacity 1.3.12.
The one thing that is a little confusing is that it seems to imply that if I want to write the file to my Desktop (/home/steve/Desktop) then I should be able to append “/Desktop” to the default “HOME directory” (which as you will know Irish, does not work).
I sgree there could be confusion when /home is actually part of the file path (though that’s something that isn’t a problem on Windows 
).
Maybe there should be something else in the text box instead of “HOME directory”?
Default directory? User directory? Default file path? Nothing I came up with felt instinctively right.
As regards testing, I think the curve generation code is now correct, so I’m mainly interested in ensuring that I’ve caught any errors that might be generated.
POL
How about leaving that text input widget empty by default as an optional control. “Leave blank to output to home directory”
I notice that in most of your functions you have set a variable in the final line. This is not necessary as functions return the last value.
For example, if we have a simple function that adds two numbers:
(defun add (x y)
(setq z (+ x y)))
(print (add 3 5)) ; prints 8
The variable “z” is superfluous, better to write:
(defun add (x y)
(+ x y))
(print (add 3 5)) ; prints 8
Good point about the functions. I’ll tidy that up.
Yes, but how do you fit that, plus the widget title, into 27 or so characters without being too cryptic? (I’ve said 27 because I dont want the window to get any wider than it is.)
“File Path (blank = Home Dir)”?
POL
Possibly, or perhaps something like:
;control mode "Select Function / Help" choice "Generate EQ Curve,Help: EQ Curves Part 1,Help: EQ Curves Part 2,Help: This Plug-in Part 1,Help: This Plug-in Part 2,Help: Cancelling RIAA EQ" 0
;control tofreq "Turnover Frequency" real "Hz" 500.0 200.0 1000.0
;control tenkrolloff "10 kHz Gain Rolloff" real "dB" -13.656 -24.0 0.0
;control lfshelf "LF Shelving Frequency" real "Hz" 50.0 10.0 100.0
;control norm "Normalise to 0 dB at 1 kHz? " choice "Yes,No" 0
;control curname "Curve File Name" string "(max 30 char)" 78EQ
;control path "(Optional) Output Pathn(default is 'Home' directory)" string "(use / in path)"
Yes, I like that.
(It never occurred to me that there could be more than one line in the text).
POL
Thanks, POL, I grabbed v2.3.
Writing to a root directory e.g. E: is rejected on my Win7 system; it requires a folder inside E: (I’m entering “E:/” even though backslashes are accepted if you use the plug-in in SVN HEAD).
Perhaps it should throw an error for empty file name so it doesn’t write an “.xml” file?
Also perhaps ERROR WRITING OUTPUT FILE should include the possibility of putting a system-illegal character in the file name? If so, “Check that the File Name and Output Path are valid and that you have permission to write to that path.” with a minor corresponding tweak to the Help file.
Should Turnover, Rolloff and Shelving have error checking for empty or silly values? Perhaps Turnover should be checked for empty, I managed to do it once.
I too like not writing anything in the Output Path box by default, but rather than
;control path "(Optional) Output Pathn(default is 'Home' directory)" string "(use / in path)"
I’d suggest if you can tolerate the width:
;control path "(Optional) Output Pathn(leave blank to write to home directory)" string "(use / in path)"
or if too wide
;control path "(Optional) Output Pathn(default is home directory)" string "(use / in path)"
Or you could say “HOME” (without quotes) to match the capitalisation in the error message. My concern is that ‘Home’ is of course not a recognised directory on Windows and could confuse if quoted.
I’m sure you won’t, but don’t forget to empty the “equal path” in the error checking if you empty the Output File box
(if (and (equal path "")
(not (fboundp 'get-env)))
(format NIL "ERRORnnAudacity can't write the curve file, because it can'tnget the path to the HOME directory from thencomputer's operating system.nnThis may be because this version of Audacity doesn'tnsupport the required function.nnIn the input dialog, type the full path (using /, not \)nto the directory where you want to save the curve file.")
(progn
(if (equal path "")
(setq path (or (get-env "HOME")
(get-env "UserProfile"))
)
)
Pedant’s corner: the ;info line says “Generates an EQ curve and writes it to an xml file for import into Equalisation.” but it’s Effect > Equalization in Audacity. I think if you capitalise it you would have to use the “z” (of course I’m not saying to change to z in all the other instances). Maybe if you said “for import into the equalisation effect”, if you don’t want any s and z mismatches?
Gale
Being English myself, I’ve come across this quite a few times and my preference is to go for capitalisation with American spelling. I think this way it is more clear that the effect being referred to is “Effect > Equalization”. When talking about the process of equalisation, (rather than the Audacity effect) I prefer lower case and English spelling.
Also being English myself, my Oxford English Dictionary lists “capitalize” as the primary entry - with capitialse as the variant spelling 
One of my English teachers at school (a very long time ago now …) was Scottish, and he always had us spelling such words with the z rather than the s variant.
As far as the Audacity Manual and Wiki go, the rules are clear: they are to be written in American English: so Zee rules …
WC
Since this has descended into a discussion of spelling variants 
I should point out that, being Canadian, I am caught in the middle. “Colour”, not “color”. But “capitalize”, not" capitalise".
To understand our quandry: http://www.lukemastin.com/testing/spelling/cgi-bin/database.cgi?action=home
– Bill
Similarly, my XP system rejects writing to C:. I assumed it was because I wasn’t logged in with an administrator account and access was restricted, but maybe there is another reason. In any case, I think it is a bad idea in principle to write to the root directory. I assume you are getting the appropriate error message in your case?
I’ll have a look at including that.
I’m reluctant to open that can of worms unless I really have to.
“What’s considered legal? ASCII? Unicode? How does it differ between OSs? Do we check for slashes (forward or back)? or periods? Does Equalization have restrictions on the file names that can be imported, and would we have to check for those cases?”
Aaargh! …
For the text in the Output Path box, I think “(leave blank to write to home directory)” is the best from a user-information point of view, but it creates a long line sticking out to the left of the dialog window, which doesn’t look good. I could make three lines instead of two, but that leaves “directory” on its own on the third line, so I would suggest “(default is home directory)” as the best compromise.
Any strong feelings on “HOME” vs “home” (without quotes)? I can make the error message match in either case.
I can check for empty or wrong sign, but I am reluctant to put limits on values, on the basis that someone, somewhere, will come up with a good reason for entering a value outside the limit.
Of course it has to be “Equalization”, since that’s the effect name.
(See the consequences of proof-reading my own text!)
Just to add to the digression, Ireland’s education system was modelled on the British one, but we were taught “colour”, “capitalise”, “dialogue” were correct, and those other variants were a new-fangled American notion which would never catch on!
POL
Re. error checking, I think that it’s worth taking into account the “target audience”.
With some types of plug-ins (such as this one, my “wave stats” and “sample printer”), these are “technical” plug-ins that are only of interest to “geeks”, who should realise that if you enter stupid values, you will get stupid results.
In comparison, plug-ins such as the “notch filter” that Bill and I spent so much time on, are aimed at being useful to “general users”, and as such should be idiot proof/bullet proof.
For “technical” plug-ins I think that it is sufficient if it is clear how to use the plug-in correctly.
Manual (which is a wiki), yes. Main Wiki (wiki.audacityteam.org), I think it’s unenforceable because someone of the “opposite” nationality will always come along and change it to the “correct” spelling for their country. The only thing I usually try to enforce is that the usage is consistent within the same page.
Gale
Yes, in fact that’s part of my problem because in my case (E:) clearly the path is valid and writable. Moreover, Equalization can export xml curves to root dirs so there will be some sort of expectation that curves generator can. Is it a restriction with Nyquist?
For reference, the Windows and Mac “illegal characters” and other restrictions are listed here:
i.e. / : * ? " < > | are illegal on Windows and colon : is illegal on Mac. On Linux, only / (the file separator) and the null character are illegal AFAIK. The reason “/” is legal on Mac despite being the file separator is that it is translated internally - to colon, I think.
However I wasn’t meaning that the plug-in code needs to do error-checking for system-illegal file names - the OS can do that. I just questioned if the error message should allow the possibility that an illegal character is the reason for the rejection. The message implies so in saying “check the path is valid”, but I think that is a very geeky interpretation of whether the path is valid. So I’m only suggesting a rewording to:
“Check that the File Name and Output Folder are valid and that you have permission to write to that path.”
with a minor corresponding tweak to the Help file.
Fine.
I think “home” is more user-friendly.
OK, just check for empty/wrong.
I agree with Steve about “tailor the error message to the target audience”, though I think this plug-in is not that geeky as there will be Wiki information giving sets of three values for various curves for entry into the plug-in; user won’t need to understand what the terms mean.
Gale