Re: [Audacity-nyquist] [Audacity-quality] Floating point input from slider widget

[Vaughan J. <va...@au...>]

I received this in audacity-nyquist digest today, and the earliest
message in it is dated Sep 2! So, I requested the moderator make it send
out digests more frequently.

Steve, I wasn't ignoring you, I just hadn't seen your message until now.
Cc-ing this to -devel because it needs input from a Linux developer.

I'm including my full message to which Steve responded, because he
deleted some of it that is relevant to a Linus developer helping on this.

The original problem was that if the type (int/float) for a slider
control was specified incorrectly, it defaulted to creating an int. I
made it check the specification and warn on an error. Somehow the thread
got split, but it's:

http://audacity.238276.n2.nabble.com/Re-Audacity-quality-Floating-point-input-from-slider-widget-td5470685.html#a5470685

and

http://audacity.238276.n2.nabble.com/Re-Audacity-quality-Floating-point-input-from-slider-widget-td5493819.html#a5493819



> ------------------------------
> 
> Message: 2
> Date: Thu, 02 Sep 2010 19:39:33 -0700
> From: Vaughan Johnson <va...@au...>
<snip>
>> Date: Sat, 28 Aug 2010 06:54:25 +0200
>> From: edgar <edg...@we...>
>> <snip>
>>  Steve:
>>  >> Ignoring the control would be consistent with how Audacity treats other
>>  >> malformed controls, though a debug message would certainly be more
>>  >> helpful. Would it be possible to send a message to the debug window just
>>  >> to say that a control has been ignored?
>>  >>
>>  Vaughan:
>>  >> Unfortunately, the place it can be detected is at startup, when all the
>>  >> Nyquist plugins are loaded, in a method that parses a single line. The
>>  >> debug window is used when the plugin is invoked, in a far distant piece
>>  >> of code.
>>  Vaughan:
>>  > * If it's not "real", "float", or "int" it fails to create the control.
>>  > It puts up a warning alert box. This all occurs before the Audacity Log
>>  > window is created, so it does not go to the log...
>>
Edgar:
>> Sounds to me like a workaround, but is far better than ignoring the bug.
> 
Vaughan:
> Actually, not a workaround. Because the Nyquist plugins are parsed at
> startup (so they need not be parsed every invocation), that's where the
> error can be detected, not on invocation.
> 
> Was asking whether people prefer alert dialog (as for some other Nyquist
> errors that get caught) or the log (without alert dialog).
> 
> 
> 
>>
>>  > That raises the general question of whether to create the log window
>>  > earlier, so the message goes to the log, but then does *not* bring up
>>  > an alert box. Comments?
>>
Edgar:
>> It that's no huge code surgery this is the far better solution. I think
>> an alert box is OK for developers, but probably will annoy the casual
>> user, who just simply expects a plugin to work.
> 
Vaughan:
> Well, we should always QA any plugin we're supplying with Audacity
> before releasing it, certainly to the point of parsing it once. So users
> should not see these, and the developer will get a prominent alert
> rather than it being just treated as int without notification.
> 
> Thanks!
> 
> - Vaughan
> 
> 
> ------------------------------
> 
> Message: 4
> Date: Sun, 5 Sep 2010 17:29:50 -0700 (PDT)
> From: Stevethefiddle <ste...@gm...>
> 
> Vaughan Johnson wrote:
>>
>> Was asking whether people prefer alert dialog (as for some other Nyquist
>> errors that get caught) or the log (without alert dialog).
>>
> 
> As with other types of plug-ins we have no control over what plug-ins users
> are going to install. 

Of course. That's why I made my changes, which work great on Windows...


> 
> What I'm seeing (on Linux) is that if a user installs a Nyquist plug-in that
> has an invalid data type in the control line then Audacity will fail to
> launch and the user will see no notification as to why it has failed. 

Wow, disappointing that the behavior is so different. On Windows,
wxWidgets brings up the main Audacity window and then a warning alert
box describing the problem (as I wrote).

All I'm doing is calling wxLogWarning. On Windows, it brings up an alert
box after the main Audacity window is up. I had tried calling
wxMessageBox, but on Windows, it comes up before the main Audacity
window, so is disturbing, as it's not visually related to any app.

But the reason wxLogWarning brings up a dialog instead of writing to the
log is that the Audacity wxApp's logger hasn't been set up at the point
the plugins are loaded. So my question was whether to set up the logger
earlier, write the error to the log, and call wxMessageBox as well,
after the main Audacity window is up.

>From what you say, the latter may be the best idea, if it works on
Linux. If we don't get any input on -devel about this, I'll try that.


> 
> On the other hand, if there are any errors in the control line other than an
> invalid data type, then Audacity will launch without any sort of error,
> other than the control line is ignored. For example:
> 
> correctly formed slider control - works correctly - 
> ;control level-red "Level reduction" real "dB" -12 -100 0
> 
> invalid type - Audacity does not launch (error produced if Audacity is
> launched from command line)
> ;control level-red "Level reduction" reel "dB" -12 -100 0

That works differently on Windows, brings up an alert box saying "reel"
is a bad type specifier.


> 
> only two parameters given instead of 3 - no error, control ignored - 
> ;control level-red "Level reduction" real "dB" -12 -100

There's *very* little error checking and next to no warning done in
loading the Nyquist plugins. Been that way a long time.

It does count the args and bails without warning if the count is wrong.
I didn't change anything in that regard. There are numerous other places
that just bail. As you wrote, "Ignoring the control would be consistent
with how Audacity treats other malformed controls..."


> 
> 
> I don't think we can have Audacity failing to open without any indication to
> the user as to why it has failed.

I had no idea it was behaving so differently on Linux. As I wrote, my
changes were precisely to change it from ignoring the error and creating
an int, to warning about it. :-)

- Vaughan