Additional message in Debug output

classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|

Additional message in Debug output

Robert Hänggi
The recently added
"Nyquist error returned from Nyquist Prompt:" is imho pretty useless
and annoying.
This belongs to the title bar if anywhere.
There is absolute no error in the code when I simply want to debug a
variable or property or some other information.
Also, the "Nyquist returned NIL" is still reported in the log file and
thus cluttering it unnecessarily.

Robert

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Audacity-quality mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-quality
Reply | Threaded
Open this post in threaded view
|

Re: Additional message in Debug output

Stevethefiddle
I am considering removing that as I agree it does not appear to be
very useful, but it does provide information about what Nyquist is
doing that is not otherwise available.

If, for example, you view the debug output from the Nyquist Prompt
from the command:
(print "Hello World")
You will see there is no error reported.

On the other hand, if you do the same with the command:
(print (list "Hello World"))
then you will see the error message:

"Nyquist error returned from Nyquist Prompt:
("Hello World")"

The reason that you see the error message in the latter case, is
because a string list is not defined as a valid return type. Anything
that is not defined as a valid return type is defined as an error
type. The change is that the debug window now tells you that Nyquist
has returned an error type rather than not telling you.

I think the question is whether it is useful for debugging purposes to
know whether the returned type is a string or an "error" type.
Previously we have hidden that information.

Steve

On 12 June 2017 at 10:37, Robert Hänggi <[hidden email]> wrote:

> The recently added
> "Nyquist error returned from Nyquist Prompt:" is imho pretty useless
> and annoying.
> This belongs to the title bar if anywhere.
> There is absolute no error in the code when I simply want to debug a
> variable or property or some other information.
> Also, the "Nyquist returned NIL" is still reported in the log file and
> thus cluttering it unnecessarily.
>
> Robert
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Audacity-quality mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/audacity-quality

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Audacity-quality mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-quality
Reply | Threaded
Open this post in threaded view
|

Re: Additional message in Debug output

Robert Hänggi
Thanks for replying Steve.
I find the message itself superfluous (in the debug multi-line pane).
As I said, it could go to the title.
The message should imply that no valid output has been returned,
rather than saying that it was an error.

It is in general nice that the debug output opens automatically on
raised errors.
That's very handy for plug-ins without GUI.

What I would like to have is:
- A facility to turn the debug window off in absolute terms, even if
mDebugOutput (nyquist.cpp) is not empty, i.e. another switch for
debugflags.
- Not to display an empty debug window when the return value is NIL or
rather to define a valid dummy return (see below).

The problem I'm facing is the following:
I have a bunch of 15 plug-ins that are self-voiced.
They report all kind of things such as Peak, Rms, Gain, Frequency,
Tempo and so on.
On Linux and Mac, the information is returned as message box.
However, on Windows it is returned as natural speech.

Your changes do that
1. the debug window opens automatically
2. the warning "Nyquist returned NIL" is logged.
I can't produce an artificial output because this would defeat the
purpose of the plug-ins since an message box would appear.
A good solution would be that an empty string ("") as last statement
is a valid return possibility and it would neither trigger a message
box nor a log entry.
In this fashion, NIL could still raise an error and thus indicate a
problem with the code.
You can see it likewise as a kind of "Skip processing this track"
For instance:
(if (soundp *track*)
    do something
;else
"")

In other words, process only mono tracks that are selected.

Robert


On 12/06/2017, Steve the Fiddle <[hidden email]> wrote:

> I am considering removing that as I agree it does not appear to be
> very useful, but it does provide information about what Nyquist is
> doing that is not otherwise available.
>
> If, for example, you view the debug output from the Nyquist Prompt
> from the command:
> (print "Hello World")
> You will see there is no error reported.
>
> On the other hand, if you do the same with the command:
> (print (list "Hello World"))
> then you will see the error message:
>
> "Nyquist error returned from Nyquist Prompt:
> ("Hello World")"
>
> The reason that you see the error message in the latter case, is
> because a string list is not defined as a valid return type. Anything
> that is not defined as a valid return type is defined as an error
> type. The change is that the debug window now tells you that Nyquist
> has returned an error type rather than not telling you.
>
> I think the question is whether it is useful for debugging purposes to
> know whether the returned type is a string or an "error" type.
> Previously we have hidden that information.
>
> Steve
>
> On 12 June 2017 at 10:37, Robert Hänggi <[hidden email]> wrote:
>> The recently added
>> "Nyquist error returned from Nyquist Prompt:" is imho pretty useless
>> and annoying.
>> This belongs to the title bar if anywhere.
>> There is absolute no error in the code when I simply want to debug a
>> variable or property or some other information.
>> Also, the "Nyquist returned NIL" is still reported in the log file and
>> thus cluttering it unnecessarily.
>>
>> Robert
>>
>> ------------------------------------------------------------------------------
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> _______________________________________________
>> Audacity-quality mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Audacity-quality mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Audacity-quality mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-quality
Reply | Threaded
Open this post in threaded view
|

Re: Additional message in Debug output

Stevethefiddle
On 12 June 2017 at 12:19, Robert Hänggi <[hidden email]> wrote:
> Thanks for replying Steve.
> I find the message itself superfluous (in the debug multi-line pane).
> As I said, it could go to the title.

Not really, because the debug window does not necessarily return
"errors". It would be wrong for the debug window to be titled as an
error output if it only contained non-error debug "information".

On the other hand, the debug window could include error messages and
still have a valid return value. Unless we parse the entire debug
output we don't know if the debug information includes errors, but we
do know if the returned value is a valid type.


> The message should imply that no valid output has been returned,
> rather than saying that it was an error.

The message is triggered when the returned value == nyx_error

>
> It is in general nice that the debug output opens automatically on
> raised errors.
> That's very handy for plug-ins without GUI.

That's the idea.
We don't however want to automatically open the debug window for
non-error debug information that Nyquist may return.

>
> What I would like to have is:
> - A facility to turn the debug window off in absolute terms, even if
> mDebugOutput (nyquist.cpp) is not empty, i.e. another switch for
> debugflags.
> - Not to display an empty debug window when the return value is NIL or
> rather to define a valid dummy return (see below).

It would be possible to provide a flag that completely disables debug
output, but I'm not sure that will do what you want. We shouldn't rely
on "errors" to perform the actions that we require. I'm -1 for
building on bugs.

>
> The problem I'm facing is the following:
> I have a bunch of 15 plug-ins that are self-voiced.
> They report all kind of things such as Peak, Rms, Gain, Frequency,
> Tempo and so on.
> On Linux and Mac, the information is returned as message box.
> However, on Windows it is returned as natural speech.

How are you doing that? If you return text from the plug-in it should
be displayed as an accessible text message (and no error). Does that
not happen?

>
> Your changes do that
> 1. the debug window opens automatically
> 2. the warning "Nyquist returned NIL" is logged.

That's a debug message that lets plug-in developers know that their
plug-in returned nil, which can be important information for
debugging. I agree that "nil" should not be treated as an error,
because we explicitly handle it as a return value.

Steve

> I can't produce an artificial output because this would defeat the
> purpose of the plug-ins since an message box would appear.
> A good solution would be that an empty string ("") as last statement
> is a valid return possibility and it would neither trigger a message
> box nor a log entry.
> In this fashion, NIL could still raise an error and thus indicate a
> problem with the code.
> You can see it likewise as a kind of "Skip processing this track"
> For instance:
> (if (soundp *track*)
>     do something
> ;else
> "")
>
> In other words, process only mono tracks that are selected.
>
> Robert
>
>
> On 12/06/2017, Steve the Fiddle <[hidden email]> wrote:
>> I am considering removing that as I agree it does not appear to be
>> very useful, but it does provide information about what Nyquist is
>> doing that is not otherwise available.
>>
>> If, for example, you view the debug output from the Nyquist Prompt
>> from the command:
>> (print "Hello World")
>> You will see there is no error reported.
>>
>> On the other hand, if you do the same with the command:
>> (print (list "Hello World"))
>> then you will see the error message:
>>
>> "Nyquist error returned from Nyquist Prompt:
>> ("Hello World")"
>>
>> The reason that you see the error message in the latter case, is
>> because a string list is not defined as a valid return type. Anything
>> that is not defined as a valid return type is defined as an error
>> type. The change is that the debug window now tells you that Nyquist
>> has returned an error type rather than not telling you.
>>
>> I think the question is whether it is useful for debugging purposes to
>> know whether the returned type is a string or an "error" type.
>> Previously we have hidden that information.
>>
>> Steve
>>
>> On 12 June 2017 at 10:37, Robert Hänggi <[hidden email]> wrote:
>>> The recently added
>>> "Nyquist error returned from Nyquist Prompt:" is imho pretty useless
>>> and annoying.
>>> This belongs to the title bar if anywhere.
>>> There is absolute no error in the code when I simply want to debug a
>>> variable or property or some other information.
>>> Also, the "Nyquist returned NIL" is still reported in the log file and
>>> thus cluttering it unnecessarily.
>>>
>>> Robert
>>>
>>> ------------------------------------------------------------------------------
>>> Check out the vibrant tech community on one of the world's most
>>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>>> _______________________________________________
>>> Audacity-quality mailing list
>>> [hidden email]
>>> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>>
>> ------------------------------------------------------------------------------
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> _______________________________________________
>> Audacity-quality mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Audacity-quality mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/audacity-quality

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Audacity-quality mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-quality
Reply | Threaded
Open this post in threaded view
|

Re: Additional message in Debug output

Robert Hänggi
Treating NIL as valid is probably fine although a bit
counter-intuitive (from a C point of view)
It would at least free me from introducing a version control 2.1.3 vs 2.2.0.
What about a returned value of 't' (true) shouldn't that be treated
specially too?

Robert

On 12/06/2017, Steve the Fiddle <[hidden email]> wrote:

> On 12 June 2017 at 12:19, Robert Hänggi <[hidden email]> wrote:
>> Thanks for replying Steve.
>> I find the message itself superfluous (in the debug multi-line pane).
>> As I said, it could go to the title.
>
> Not really, because the debug window does not necessarily return
> "errors". It would be wrong for the debug window to be titled as an
> error output if it only contained non-error debug "information".
>
> On the other hand, the debug window could include error messages and
> still have a valid return value. Unless we parse the entire debug
> output we don't know if the debug information includes errors, but we
> do know if the returned value is a valid type.
>
>
>> The message should imply that no valid output has been returned,
>> rather than saying that it was an error.
>
> The message is triggered when the returned value == nyx_error
>
>>
>> It is in general nice that the debug output opens automatically on
>> raised errors.
>> That's very handy for plug-ins without GUI.
>
> That's the idea.
> We don't however want to automatically open the debug window for
> non-error debug information that Nyquist may return.
>
>>
>> What I would like to have is:
>> - A facility to turn the debug window off in absolute terms, even if
>> mDebugOutput (nyquist.cpp) is not empty, i.e. another switch for
>> debugflags.
>> - Not to display an empty debug window when the return value is NIL or
>> rather to define a valid dummy return (see below).
>
> It would be possible to provide a flag that completely disables debug
> output, but I'm not sure that will do what you want. We shouldn't rely
> on "errors" to perform the actions that we require. I'm -1 for
> building on bugs.
>
>>
>> The problem I'm facing is the following:
>> I have a bunch of 15 plug-ins that are self-voiced.
>> They report all kind of things such as Peak, Rms, Gain, Frequency,
>> Tempo and so on.
>> On Linux and Mac, the information is returned as message box.
>> However, on Windows it is returned as natural speech.
>
> How are you doing that? If you return text from the plug-in it should
> be displayed as an accessible text message (and no error). Does that
> not happen?
>
>>
>> Your changes do that
>> 1. the debug window opens automatically
>> 2. the warning "Nyquist returned NIL" is logged.
>
> That's a debug message that lets plug-in developers know that their
> plug-in returned nil, which can be important information for
> debugging. I agree that "nil" should not be treated as an error,
> because we explicitly handle it as a return value.
>
> Steve
>
>> I can't produce an artificial output because this would defeat the
>> purpose of the plug-ins since an message box would appear.
>> A good solution would be that an empty string ("") as last statement
>> is a valid return possibility and it would neither trigger a message
>> box nor a log entry.
>> In this fashion, NIL could still raise an error and thus indicate a
>> problem with the code.
>> You can see it likewise as a kind of "Skip processing this track"
>> For instance:
>> (if (soundp *track*)
>>     do something
>> ;else
>> "")
>>
>> In other words, process only mono tracks that are selected.
>>
>> Robert
>>
>>
>> On 12/06/2017, Steve the Fiddle <[hidden email]> wrote:
>>> I am considering removing that as I agree it does not appear to be
>>> very useful, but it does provide information about what Nyquist is
>>> doing that is not otherwise available.
>>>
>>> If, for example, you view the debug output from the Nyquist Prompt
>>> from the command:
>>> (print "Hello World")
>>> You will see there is no error reported.
>>>
>>> On the other hand, if you do the same with the command:
>>> (print (list "Hello World"))
>>> then you will see the error message:
>>>
>>> "Nyquist error returned from Nyquist Prompt:
>>> ("Hello World")"
>>>
>>> The reason that you see the error message in the latter case, is
>>> because a string list is not defined as a valid return type. Anything
>>> that is not defined as a valid return type is defined as an error
>>> type. The change is that the debug window now tells you that Nyquist
>>> has returned an error type rather than not telling you.
>>>
>>> I think the question is whether it is useful for debugging purposes to
>>> know whether the returned type is a string or an "error" type.
>>> Previously we have hidden that information.
>>>
>>> Steve
>>>
>>> On 12 June 2017 at 10:37, Robert Hänggi <[hidden email]> wrote:
>>>> The recently added
>>>> "Nyquist error returned from Nyquist Prompt:" is imho pretty useless
>>>> and annoying.
>>>> This belongs to the title bar if anywhere.
>>>> There is absolute no error in the code when I simply want to debug a
>>>> variable or property or some other information.
>>>> Also, the "Nyquist returned NIL" is still reported in the log file and
>>>> thus cluttering it unnecessarily.
>>>>
>>>> Robert
>>>>
>>>> ------------------------------------------------------------------------------
>>>> Check out the vibrant tech community on one of the world's most
>>>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>>>> _______________________________________________
>>>> Audacity-quality mailing list
>>>> [hidden email]
>>>> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>>>
>>> ------------------------------------------------------------------------------
>>> Check out the vibrant tech community on one of the world's most
>>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>>> _______________________________________________
>>> Audacity-quality mailing list
>>> [hidden email]
>>> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>>>
>>
>> ------------------------------------------------------------------------------
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> _______________________________________________
>> Audacity-quality mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Audacity-quality mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Audacity-quality mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-quality
Reply | Threaded
Open this post in threaded view
|

Re: Additional message in Debug output

Stevethefiddle
From a debugging point of view, which is after all the purpose of the
debug window, it would probably be most useful to report boolean
return values.

Steve

On 12 June 2017 at 14:39, Robert Hänggi <[hidden email]> wrote:

> Treating NIL as valid is probably fine although a bit
> counter-intuitive (from a C point of view)
> It would at least free me from introducing a version control 2.1.3 vs 2.2.0.
> What about a returned value of 't' (true) shouldn't that be treated
> specially too?
>
> Robert
>
> On 12/06/2017, Steve the Fiddle <[hidden email]> wrote:
>> On 12 June 2017 at 12:19, Robert Hänggi <[hidden email]> wrote:
>>> Thanks for replying Steve.
>>> I find the message itself superfluous (in the debug multi-line pane).
>>> As I said, it could go to the title.
>>
>> Not really, because the debug window does not necessarily return
>> "errors". It would be wrong for the debug window to be titled as an
>> error output if it only contained non-error debug "information".
>>
>> On the other hand, the debug window could include error messages and
>> still have a valid return value. Unless we parse the entire debug
>> output we don't know if the debug information includes errors, but we
>> do know if the returned value is a valid type.
>>
>>
>>> The message should imply that no valid output has been returned,
>>> rather than saying that it was an error.
>>
>> The message is triggered when the returned value == nyx_error
>>
>>>
>>> It is in general nice that the debug output opens automatically on
>>> raised errors.
>>> That's very handy for plug-ins without GUI.
>>
>> That's the idea.
>> We don't however want to automatically open the debug window for
>> non-error debug information that Nyquist may return.
>>
>>>
>>> What I would like to have is:
>>> - A facility to turn the debug window off in absolute terms, even if
>>> mDebugOutput (nyquist.cpp) is not empty, i.e. another switch for
>>> debugflags.
>>> - Not to display an empty debug window when the return value is NIL or
>>> rather to define a valid dummy return (see below).
>>
>> It would be possible to provide a flag that completely disables debug
>> output, but I'm not sure that will do what you want. We shouldn't rely
>> on "errors" to perform the actions that we require. I'm -1 for
>> building on bugs.
>>
>>>
>>> The problem I'm facing is the following:
>>> I have a bunch of 15 plug-ins that are self-voiced.
>>> They report all kind of things such as Peak, Rms, Gain, Frequency,
>>> Tempo and so on.
>>> On Linux and Mac, the information is returned as message box.
>>> However, on Windows it is returned as natural speech.
>>
>> How are you doing that? If you return text from the plug-in it should
>> be displayed as an accessible text message (and no error). Does that
>> not happen?
>>
>>>
>>> Your changes do that
>>> 1. the debug window opens automatically
>>> 2. the warning "Nyquist returned NIL" is logged.
>>
>> That's a debug message that lets plug-in developers know that their
>> plug-in returned nil, which can be important information for
>> debugging. I agree that "nil" should not be treated as an error,
>> because we explicitly handle it as a return value.
>>
>> Steve
>>
>>> I can't produce an artificial output because this would defeat the
>>> purpose of the plug-ins since an message box would appear.
>>> A good solution would be that an empty string ("") as last statement
>>> is a valid return possibility and it would neither trigger a message
>>> box nor a log entry.
>>> In this fashion, NIL could still raise an error and thus indicate a
>>> problem with the code.
>>> You can see it likewise as a kind of "Skip processing this track"
>>> For instance:
>>> (if (soundp *track*)
>>>     do something
>>> ;else
>>> "")
>>>
>>> In other words, process only mono tracks that are selected.
>>>
>>> Robert
>>>
>>>
>>> On 12/06/2017, Steve the Fiddle <[hidden email]> wrote:
>>>> I am considering removing that as I agree it does not appear to be
>>>> very useful, but it does provide information about what Nyquist is
>>>> doing that is not otherwise available.
>>>>
>>>> If, for example, you view the debug output from the Nyquist Prompt
>>>> from the command:
>>>> (print "Hello World")
>>>> You will see there is no error reported.
>>>>
>>>> On the other hand, if you do the same with the command:
>>>> (print (list "Hello World"))
>>>> then you will see the error message:
>>>>
>>>> "Nyquist error returned from Nyquist Prompt:
>>>> ("Hello World")"
>>>>
>>>> The reason that you see the error message in the latter case, is
>>>> because a string list is not defined as a valid return type. Anything
>>>> that is not defined as a valid return type is defined as an error
>>>> type. The change is that the debug window now tells you that Nyquist
>>>> has returned an error type rather than not telling you.
>>>>
>>>> I think the question is whether it is useful for debugging purposes to
>>>> know whether the returned type is a string or an "error" type.
>>>> Previously we have hidden that information.
>>>>
>>>> Steve
>>>>
>>>> On 12 June 2017 at 10:37, Robert Hänggi <[hidden email]> wrote:
>>>>> The recently added
>>>>> "Nyquist error returned from Nyquist Prompt:" is imho pretty useless
>>>>> and annoying.
>>>>> This belongs to the title bar if anywhere.
>>>>> There is absolute no error in the code when I simply want to debug a
>>>>> variable or property or some other information.
>>>>> Also, the "Nyquist returned NIL" is still reported in the log file and
>>>>> thus cluttering it unnecessarily.
>>>>>
>>>>> Robert
>>>>>
>>>>> ------------------------------------------------------------------------------
>>>>> Check out the vibrant tech community on one of the world's most
>>>>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>>>>> _______________________________________________
>>>>> Audacity-quality mailing list
>>>>> [hidden email]
>>>>> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>>>>
>>>> ------------------------------------------------------------------------------
>>>> Check out the vibrant tech community on one of the world's most
>>>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>>>> _______________________________________________
>>>> Audacity-quality mailing list
>>>> [hidden email]
>>>> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Check out the vibrant tech community on one of the world's most
>>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>>> _______________________________________________
>>> Audacity-quality mailing list
>>> [hidden email]
>>> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>>
>> ------------------------------------------------------------------------------
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> _______________________________________________
>> Audacity-quality mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Audacity-quality mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/audacity-quality

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Audacity-quality mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-quality
Reply | Threaded
Open this post in threaded view
|

Re: Additional message in Debug output

Stevethefiddle
Perhaps better for you now Robert.

I was wrong about boolean return values. We don't currently handle
them any differently from other non-valid return types. Changing that
requires modifying files in lib-src so I've left that for now.

This will all be documented in due course, but briefly:

When "debugflags" is set to "trace", the debug window will open if
there is anything to show.

when "debugflags" is set to "notrace", error logging is redirected to
the Audacity log.

When the Debug button is pressed, the debug window will open
regardless of whether there is anything to show.

To enable trace without enabling automatic opening of the debug
window, set *tracenable* in the Nyquist code.

To always open the debug window on error with brief error messages,
set "debugflags" to "trace" and *tracenable* to nil at the top of the
Nyquist code.

To show text in the debug window without triggering an error and
without requiring the debug button to be pressed, set debugflags to
trace and return a valid data type. An empty string is a valid return
value. Unmodified *track* is a valid return value.

We don't currently have a "dummy" return value, but we could add one.
I'm not too keen on using an empty string as a dummy, because that
could be confusing when debugging code that should return a message
but due to a bug returns an empty string. A special string value would
be the easiest to implement as a dummy, for example: "*no-print*". Do
we need a dummy return value?

Steve


On 12 June 2017 at 15:02, Steve the Fiddle <[hidden email]> wrote:

> From a debugging point of view, which is after all the purpose of the
> debug window, it would probably be most useful to report boolean
> return values.
>
> Steve
>
> On 12 June 2017 at 14:39, Robert Hänggi <[hidden email]> wrote:
>> Treating NIL as valid is probably fine although a bit
>> counter-intuitive (from a C point of view)
>> It would at least free me from introducing a version control 2.1.3 vs 2.2.0.
>> What about a returned value of 't' (true) shouldn't that be treated
>> specially too?
>>
>> Robert
>>
>> On 12/06/2017, Steve the Fiddle <[hidden email]> wrote:
>>> On 12 June 2017 at 12:19, Robert Hänggi <[hidden email]> wrote:
>>>> Thanks for replying Steve.
>>>> I find the message itself superfluous (in the debug multi-line pane).
>>>> As I said, it could go to the title.
>>>
>>> Not really, because the debug window does not necessarily return
>>> "errors". It would be wrong for the debug window to be titled as an
>>> error output if it only contained non-error debug "information".
>>>
>>> On the other hand, the debug window could include error messages and
>>> still have a valid return value. Unless we parse the entire debug
>>> output we don't know if the debug information includes errors, but we
>>> do know if the returned value is a valid type.
>>>
>>>
>>>> The message should imply that no valid output has been returned,
>>>> rather than saying that it was an error.
>>>
>>> The message is triggered when the returned value == nyx_error
>>>
>>>>
>>>> It is in general nice that the debug output opens automatically on
>>>> raised errors.
>>>> That's very handy for plug-ins without GUI.
>>>
>>> That's the idea.
>>> We don't however want to automatically open the debug window for
>>> non-error debug information that Nyquist may return.
>>>
>>>>
>>>> What I would like to have is:
>>>> - A facility to turn the debug window off in absolute terms, even if
>>>> mDebugOutput (nyquist.cpp) is not empty, i.e. another switch for
>>>> debugflags.
>>>> - Not to display an empty debug window when the return value is NIL or
>>>> rather to define a valid dummy return (see below).
>>>
>>> It would be possible to provide a flag that completely disables debug
>>> output, but I'm not sure that will do what you want. We shouldn't rely
>>> on "errors" to perform the actions that we require. I'm -1 for
>>> building on bugs.
>>>
>>>>
>>>> The problem I'm facing is the following:
>>>> I have a bunch of 15 plug-ins that are self-voiced.
>>>> They report all kind of things such as Peak, Rms, Gain, Frequency,
>>>> Tempo and so on.
>>>> On Linux and Mac, the information is returned as message box.
>>>> However, on Windows it is returned as natural speech.
>>>
>>> How are you doing that? If you return text from the plug-in it should
>>> be displayed as an accessible text message (and no error). Does that
>>> not happen?
>>>
>>>>
>>>> Your changes do that
>>>> 1. the debug window opens automatically
>>>> 2. the warning "Nyquist returned NIL" is logged.
>>>
>>> That's a debug message that lets plug-in developers know that their
>>> plug-in returned nil, which can be important information for
>>> debugging. I agree that "nil" should not be treated as an error,
>>> because we explicitly handle it as a return value.
>>>
>>> Steve
>>>
>>>> I can't produce an artificial output because this would defeat the
>>>> purpose of the plug-ins since an message box would appear.
>>>> A good solution would be that an empty string ("") as last statement
>>>> is a valid return possibility and it would neither trigger a message
>>>> box nor a log entry.
>>>> In this fashion, NIL could still raise an error and thus indicate a
>>>> problem with the code.
>>>> You can see it likewise as a kind of "Skip processing this track"
>>>> For instance:
>>>> (if (soundp *track*)
>>>>     do something
>>>> ;else
>>>> "")
>>>>
>>>> In other words, process only mono tracks that are selected.
>>>>
>>>> Robert
>>>>
>>>>
>>>> On 12/06/2017, Steve the Fiddle <[hidden email]> wrote:
>>>>> I am considering removing that as I agree it does not appear to be
>>>>> very useful, but it does provide information about what Nyquist is
>>>>> doing that is not otherwise available.
>>>>>
>>>>> If, for example, you view the debug output from the Nyquist Prompt
>>>>> from the command:
>>>>> (print "Hello World")
>>>>> You will see there is no error reported.
>>>>>
>>>>> On the other hand, if you do the same with the command:
>>>>> (print (list "Hello World"))
>>>>> then you will see the error message:
>>>>>
>>>>> "Nyquist error returned from Nyquist Prompt:
>>>>> ("Hello World")"
>>>>>
>>>>> The reason that you see the error message in the latter case, is
>>>>> because a string list is not defined as a valid return type. Anything
>>>>> that is not defined as a valid return type is defined as an error
>>>>> type. The change is that the debug window now tells you that Nyquist
>>>>> has returned an error type rather than not telling you.
>>>>>
>>>>> I think the question is whether it is useful for debugging purposes to
>>>>> know whether the returned type is a string or an "error" type.
>>>>> Previously we have hidden that information.
>>>>>
>>>>> Steve
>>>>>
>>>>> On 12 June 2017 at 10:37, Robert Hänggi <[hidden email]> wrote:
>>>>>> The recently added
>>>>>> "Nyquist error returned from Nyquist Prompt:" is imho pretty useless
>>>>>> and annoying.
>>>>>> This belongs to the title bar if anywhere.
>>>>>> There is absolute no error in the code when I simply want to debug a
>>>>>> variable or property or some other information.
>>>>>> Also, the "Nyquist returned NIL" is still reported in the log file and
>>>>>> thus cluttering it unnecessarily.
>>>>>>
>>>>>> Robert
>>>>>>
>>>>>> ------------------------------------------------------------------------------
>>>>>> Check out the vibrant tech community on one of the world's most
>>>>>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>>>>>> _______________________________________________
>>>>>> Audacity-quality mailing list
>>>>>> [hidden email]
>>>>>> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>>>>>
>>>>> ------------------------------------------------------------------------------
>>>>> Check out the vibrant tech community on one of the world's most
>>>>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>>>>> _______________________________________________
>>>>> Audacity-quality mailing list
>>>>> [hidden email]
>>>>> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>>>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>> Check out the vibrant tech community on one of the world's most
>>>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>>>> _______________________________________________
>>>> Audacity-quality mailing list
>>>> [hidden email]
>>>> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>>>
>>> ------------------------------------------------------------------------------
>>> Check out the vibrant tech community on one of the world's most
>>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>>> _______________________________________________
>>> Audacity-quality mailing list
>>> [hidden email]
>>> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>>>
>>
>> ------------------------------------------------------------------------------
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> _______________________________________________
>> Audacity-quality mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/audacity-quality

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Audacity-quality mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-quality
Reply | Threaded
Open this post in threaded view
|

Re: Additional message in Debug output

Robert Hänggi
Thanks Steve

The plug-ins work again but still with the floor that they are logged
as "Warning: Nyquist returned nyx_error." (in most cases not relevant
to the user because it's hidden)
that's why I said that we need a dummy return as you like to call it.

Example: one plug-in reports the selection length.
This works even if 10 tracks are selected. The duration does not
change and hence it is only spoken on the last track.
However, it will produce ten log entries nonetheless because nil is
always returned.

Here are the plug-ins, if you want to try them on a Windows machine
(for audio output).
https://www.dropbox.com/s/xzvi08mklgwsd99/tts-suite.zip?dl=1

The wav files are mandatory (tts-suite-fast.wav has precedence over
tts-suite.wav).
Thanks to Robbie Sandberg for his voice performance.
The files should directly be installed in the plug-in folder, not in a
sub folder of it.
After the "tts-xxx.ny" file is enabled in the effect manager, it will
be onwards be listed there and in the Analyse menu as "Report xxx".
The output goes (presumably) to the standard output of Windows and
volume etc have to be changed there.

Robert

On 13/06/2017, Steve the Fiddle <[hidden email]> wrote:

> Perhaps better for you now Robert.
>
> I was wrong about boolean return values. We don't currently handle
> them any differently from other non-valid return types. Changing that
> requires modifying files in lib-src so I've left that for now.
>
> This will all be documented in due course, but briefly:
>
> When "debugflags" is set to "trace", the debug window will open if
> there is anything to show.
>
> when "debugflags" is set to "notrace", error logging is redirected to
> the Audacity log.
>
> When the Debug button is pressed, the debug window will open
> regardless of whether there is anything to show.
>
> To enable trace without enabling automatic opening of the debug
> window, set *tracenable* in the Nyquist code.
>
> To always open the debug window on error with brief error messages,
> set "debugflags" to "trace" and *tracenable* to nil at the top of the
> Nyquist code.
>
> To show text in the debug window without triggering an error and
> without requiring the debug button to be pressed, set debugflags to
> trace and return a valid data type. An empty string is a valid return
> value. Unmodified *track* is a valid return value.
>
> We don't currently have a "dummy" return value, but we could add one.
> I'm not too keen on using an empty string as a dummy, because that
> could be confusing when debugging code that should return a message
> but due to a bug returns an empty string. A special string value would
> be the easiest to implement as a dummy, for example: "*no-print*". Do
> we need a dummy return value?
>
> Steve
>
>
> On 12 June 2017 at 15:02, Steve the Fiddle <[hidden email]> wrote:
>> From a debugging point of view, which is after all the purpose of the
>> debug window, it would probably be most useful to report boolean
>> return values.
>>
>> Steve
>>
>> On 12 June 2017 at 14:39, Robert Hänggi <[hidden email]> wrote:
>>> Treating NIL as valid is probably fine although a bit
>>> counter-intuitive (from a C point of view)
>>> It would at least free me from introducing a version control 2.1.3 vs
>>> 2.2.0.
>>> What about a returned value of 't' (true) shouldn't that be treated
>>> specially too?
>>>
>>> Robert
>>>
>>> On 12/06/2017, Steve the Fiddle <[hidden email]> wrote:
>>>> On 12 June 2017 at 12:19, Robert Hänggi <[hidden email]> wrote:
>>>>> Thanks for replying Steve.
>>>>> I find the message itself superfluous (in the debug multi-line pane).
>>>>> As I said, it could go to the title.
>>>>
>>>> Not really, because the debug window does not necessarily return
>>>> "errors". It would be wrong for the debug window to be titled as an
>>>> error output if it only contained non-error debug "information".
>>>>
>>>> On the other hand, the debug window could include error messages and
>>>> still have a valid return value. Unless we parse the entire debug
>>>> output we don't know if the debug information includes errors, but we
>>>> do know if the returned value is a valid type.
>>>>
>>>>
>>>>> The message should imply that no valid output has been returned,
>>>>> rather than saying that it was an error.
>>>>
>>>> The message is triggered when the returned value == nyx_error
>>>>
>>>>>
>>>>> It is in general nice that the debug output opens automatically on
>>>>> raised errors.
>>>>> That's very handy for plug-ins without GUI.
>>>>
>>>> That's the idea.
>>>> We don't however want to automatically open the debug window for
>>>> non-error debug information that Nyquist may return.
>>>>
>>>>>
>>>>> What I would like to have is:
>>>>> - A facility to turn the debug window off in absolute terms, even if
>>>>> mDebugOutput (nyquist.cpp) is not empty, i.e. another switch for
>>>>> debugflags.
>>>>> - Not to display an empty debug window when the return value is NIL or
>>>>> rather to define a valid dummy return (see below).
>>>>
>>>> It would be possible to provide a flag that completely disables debug
>>>> output, but I'm not sure that will do what you want. We shouldn't rely
>>>> on "errors" to perform the actions that we require. I'm -1 for
>>>> building on bugs.
>>>>
>>>>>
>>>>> The problem I'm facing is the following:
>>>>> I have a bunch of 15 plug-ins that are self-voiced.
>>>>> They report all kind of things such as Peak, Rms, Gain, Frequency,
>>>>> Tempo and so on.
>>>>> On Linux and Mac, the information is returned as message box.
>>>>> However, on Windows it is returned as natural speech.
>>>>
>>>> How are you doing that? If you return text from the plug-in it should
>>>> be displayed as an accessible text message (and no error). Does that
>>>> not happen?
>>>>
>>>>>
>>>>> Your changes do that
>>>>> 1. the debug window opens automatically
>>>>> 2. the warning "Nyquist returned NIL" is logged.
>>>>
>>>> That's a debug message that lets plug-in developers know that their
>>>> plug-in returned nil, which can be important information for
>>>> debugging. I agree that "nil" should not be treated as an error,
>>>> because we explicitly handle it as a return value.
>>>>
>>>> Steve
>>>>
>>>>> I can't produce an artificial output because this would defeat the
>>>>> purpose of the plug-ins since an message box would appear.
>>>>> A good solution would be that an empty string ("") as last statement
>>>>> is a valid return possibility and it would neither trigger a message
>>>>> box nor a log entry.
>>>>> In this fashion, NIL could still raise an error and thus indicate a
>>>>> problem with the code.
>>>>> You can see it likewise as a kind of "Skip processing this track"
>>>>> For instance:
>>>>> (if (soundp *track*)
>>>>>     do something
>>>>> ;else
>>>>> "")
>>>>>
>>>>> In other words, process only mono tracks that are selected.
>>>>>
>>>>> Robert
>>>>>
>>>>>
>>>>> On 12/06/2017, Steve the Fiddle <[hidden email]> wrote:
>>>>>> I am considering removing that as I agree it does not appear to be
>>>>>> very useful, but it does provide information about what Nyquist is
>>>>>> doing that is not otherwise available.
>>>>>>
>>>>>> If, for example, you view the debug output from the Nyquist Prompt
>>>>>> from the command:
>>>>>> (print "Hello World")
>>>>>> You will see there is no error reported.
>>>>>>
>>>>>> On the other hand, if you do the same with the command:
>>>>>> (print (list "Hello World"))
>>>>>> then you will see the error message:
>>>>>>
>>>>>> "Nyquist error returned from Nyquist Prompt:
>>>>>> ("Hello World")"
>>>>>>
>>>>>> The reason that you see the error message in the latter case, is
>>>>>> because a string list is not defined as a valid return type. Anything
>>>>>> that is not defined as a valid return type is defined as an error
>>>>>> type. The change is that the debug window now tells you that Nyquist
>>>>>> has returned an error type rather than not telling you.
>>>>>>
>>>>>> I think the question is whether it is useful for debugging purposes to
>>>>>> know whether the returned type is a string or an "error" type.
>>>>>> Previously we have hidden that information.
>>>>>>
>>>>>> Steve
>>>>>>
>>>>>> On 12 June 2017 at 10:37, Robert Hänggi <[hidden email]>
>>>>>> wrote:
>>>>>>> The recently added
>>>>>>> "Nyquist error returned from Nyquist Prompt:" is imho pretty useless
>>>>>>> and annoying.
>>>>>>> This belongs to the title bar if anywhere.
>>>>>>> There is absolute no error in the code when I simply want to debug a
>>>>>>> variable or property or some other information.
>>>>>>> Also, the "Nyquist returned NIL" is still reported in the log file
>>>>>>> and
>>>>>>> thus cluttering it unnecessarily.
>>>>>>>
>>>>>>> Robert
>>>>>>>
>>>>>>> ------------------------------------------------------------------------------
>>>>>>> Check out the vibrant tech community on one of the world's most
>>>>>>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>>>>>>> _______________________________________________
>>>>>>> Audacity-quality mailing list
>>>>>>> [hidden email]
>>>>>>> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>>>>>>
>>>>>> ------------------------------------------------------------------------------
>>>>>> Check out the vibrant tech community on one of the world's most
>>>>>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>>>>>> _______________________________________________
>>>>>> Audacity-quality mailing list
>>>>>> [hidden email]
>>>>>> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>>>>>>
>>>>>
>>>>> ------------------------------------------------------------------------------
>>>>> Check out the vibrant tech community on one of the world's most
>>>>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>>>>> _______________________________________________
>>>>> Audacity-quality mailing list
>>>>> [hidden email]
>>>>> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>>>>
>>>> ------------------------------------------------------------------------------
>>>> Check out the vibrant tech community on one of the world's most
>>>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>>>> _______________________________________________
>>>> Audacity-quality mailing list
>>>> [hidden email]
>>>> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Check out the vibrant tech community on one of the world's most
>>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>>> _______________________________________________
>>> Audacity-quality mailing list
>>> [hidden email]
>>> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Audacity-quality mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Audacity-quality mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-quality
Reply | Threaded
Open this post in threaded view
|

Re: Additional message in Debug output

Stevethefiddle
Thanks Robert, those plug-ins provide a good example where you want
the 'side-effects' rather than the return value.

I don't see that it's a big problem as users are mostly be unaware of
the log. I agree though that where no return value is expected or
required, the log message is just clutter, so better if we provide a
valid means of telling Audacity to "do nothing".

As a point of interest, I tested with tts-end and got the speech
output working. I had to change Audacity's playback settings, and set
the sample rate of "phrase" to a supported rate, and then it worked
perfectly.

Contrary to what I said previously, I'm now liking your idea of an
empty string as a "No-Op". It's simple to use, easy to implement, and
I don't think it's surprising if an empty string does nothing. I can't
think  of any practical use for displaying an empty string, so I've
now made that change. Please try it and let me know what you think.
Note that because it's still a returned string, it behaves like other
returned strings in that for process type plug-ins, processing stops
after the first returned result, but in the Nyquist Prompt (and
non-process types), processing continues for each selected track.

The logic involved handling logging is quite complex, so please test
as much as you can and let me know if there's any weird behaviour. I
'think' it should all be reasonably logical, and hopefully useful.

Steve


On 13 June 2017 at 13:31, Robert Hänggi <[hidden email]> wrote:

> Thanks Steve
>
> The plug-ins work again but still with the floor that they are logged
> as "Warning: Nyquist returned nyx_error." (in most cases not relevant
> to the user because it's hidden)
> that's why I said that we need a dummy return as you like to call it.
>
> Example: one plug-in reports the selection length.
> This works even if 10 tracks are selected. The duration does not
> change and hence it is only spoken on the last track.
> However, it will produce ten log entries nonetheless because nil is
> always returned.
>
> Here are the plug-ins, if you want to try them on a Windows machine
> (for audio output).
> https://www.dropbox.com/s/xzvi08mklgwsd99/tts-suite.zip?dl=1
>
> The wav files are mandatory (tts-suite-fast.wav has precedence over
> tts-suite.wav).
> Thanks to Robbie Sandberg for his voice performance.
> The files should directly be installed in the plug-in folder, not in a
> sub folder of it.
> After the "tts-xxx.ny" file is enabled in the effect manager, it will
> be onwards be listed there and in the Analyse menu as "Report xxx".
> The output goes (presumably) to the standard output of Windows and
> volume etc have to be changed there.
>
> Robert
>
> On 13/06/2017, Steve the Fiddle <[hidden email]> wrote:
>> Perhaps better for you now Robert.
>>
>> I was wrong about boolean return values. We don't currently handle
>> them any differently from other non-valid return types. Changing that
>> requires modifying files in lib-src so I've left that for now.
>>
>> This will all be documented in due course, but briefly:
>>
>> When "debugflags" is set to "trace", the debug window will open if
>> there is anything to show.
>>
>> when "debugflags" is set to "notrace", error logging is redirected to
>> the Audacity log.
>>
>> When the Debug button is pressed, the debug window will open
>> regardless of whether there is anything to show.
>>
>> To enable trace without enabling automatic opening of the debug
>> window, set *tracenable* in the Nyquist code.
>>
>> To always open the debug window on error with brief error messages,
>> set "debugflags" to "trace" and *tracenable* to nil at the top of the
>> Nyquist code.
>>
>> To show text in the debug window without triggering an error and
>> without requiring the debug button to be pressed, set debugflags to
>> trace and return a valid data type. An empty string is a valid return
>> value. Unmodified *track* is a valid return value.
>>
>> We don't currently have a "dummy" return value, but we could add one.
>> I'm not too keen on using an empty string as a dummy, because that
>> could be confusing when debugging code that should return a message
>> but due to a bug returns an empty string. A special string value would
>> be the easiest to implement as a dummy, for example: "*no-print*". Do
>> we need a dummy return value?
>>
>> Steve
>>
>>
>> On 12 June 2017 at 15:02, Steve the Fiddle <[hidden email]> wrote:
>>> From a debugging point of view, which is after all the purpose of the
>>> debug window, it would probably be most useful to report boolean
>>> return values.
>>>
>>> Steve
>>>
>>> On 12 June 2017 at 14:39, Robert Hänggi <[hidden email]> wrote:
>>>> Treating NIL as valid is probably fine although a bit
>>>> counter-intuitive (from a C point of view)
>>>> It would at least free me from introducing a version control 2.1.3 vs
>>>> 2.2.0.
>>>> What about a returned value of 't' (true) shouldn't that be treated
>>>> specially too?
>>>>
>>>> Robert
>>>>
>>>> On 12/06/2017, Steve the Fiddle <[hidden email]> wrote:
>>>>> On 12 June 2017 at 12:19, Robert Hänggi <[hidden email]> wrote:
>>>>>> Thanks for replying Steve.
>>>>>> I find the message itself superfluous (in the debug multi-line pane).
>>>>>> As I said, it could go to the title.
>>>>>
>>>>> Not really, because the debug window does not necessarily return
>>>>> "errors". It would be wrong for the debug window to be titled as an
>>>>> error output if it only contained non-error debug "information".
>>>>>
>>>>> On the other hand, the debug window could include error messages and
>>>>> still have a valid return value. Unless we parse the entire debug
>>>>> output we don't know if the debug information includes errors, but we
>>>>> do know if the returned value is a valid type.
>>>>>
>>>>>
>>>>>> The message should imply that no valid output has been returned,
>>>>>> rather than saying that it was an error.
>>>>>
>>>>> The message is triggered when the returned value == nyx_error
>>>>>
>>>>>>
>>>>>> It is in general nice that the debug output opens automatically on
>>>>>> raised errors.
>>>>>> That's very handy for plug-ins without GUI.
>>>>>
>>>>> That's the idea.
>>>>> We don't however want to automatically open the debug window for
>>>>> non-error debug information that Nyquist may return.
>>>>>
>>>>>>
>>>>>> What I would like to have is:
>>>>>> - A facility to turn the debug window off in absolute terms, even if
>>>>>> mDebugOutput (nyquist.cpp) is not empty, i.e. another switch for
>>>>>> debugflags.
>>>>>> - Not to display an empty debug window when the return value is NIL or
>>>>>> rather to define a valid dummy return (see below).
>>>>>
>>>>> It would be possible to provide a flag that completely disables debug
>>>>> output, but I'm not sure that will do what you want. We shouldn't rely
>>>>> on "errors" to perform the actions that we require. I'm -1 for
>>>>> building on bugs.
>>>>>
>>>>>>
>>>>>> The problem I'm facing is the following:
>>>>>> I have a bunch of 15 plug-ins that are self-voiced.
>>>>>> They report all kind of things such as Peak, Rms, Gain, Frequency,
>>>>>> Tempo and so on.
>>>>>> On Linux and Mac, the information is returned as message box.
>>>>>> However, on Windows it is returned as natural speech.
>>>>>
>>>>> How are you doing that? If you return text from the plug-in it should
>>>>> be displayed as an accessible text message (and no error). Does that
>>>>> not happen?
>>>>>
>>>>>>
>>>>>> Your changes do that
>>>>>> 1. the debug window opens automatically
>>>>>> 2. the warning "Nyquist returned NIL" is logged.
>>>>>
>>>>> That's a debug message that lets plug-in developers know that their
>>>>> plug-in returned nil, which can be important information for
>>>>> debugging. I agree that "nil" should not be treated as an error,
>>>>> because we explicitly handle it as a return value.
>>>>>
>>>>> Steve
>>>>>
>>>>>> I can't produce an artificial output because this would defeat the
>>>>>> purpose of the plug-ins since an message box would appear.
>>>>>> A good solution would be that an empty string ("") as last statement
>>>>>> is a valid return possibility and it would neither trigger a message
>>>>>> box nor a log entry.
>>>>>> In this fashion, NIL could still raise an error and thus indicate a
>>>>>> problem with the code.
>>>>>> You can see it likewise as a kind of "Skip processing this track"
>>>>>> For instance:
>>>>>> (if (soundp *track*)
>>>>>>     do something
>>>>>> ;else
>>>>>> "")
>>>>>>
>>>>>> In other words, process only mono tracks that are selected.
>>>>>>
>>>>>> Robert
>>>>>>
>>>>>>
>>>>>> On 12/06/2017, Steve the Fiddle <[hidden email]> wrote:
>>>>>>> I am considering removing that as I agree it does not appear to be
>>>>>>> very useful, but it does provide information about what Nyquist is
>>>>>>> doing that is not otherwise available.
>>>>>>>
>>>>>>> If, for example, you view the debug output from the Nyquist Prompt
>>>>>>> from the command:
>>>>>>> (print "Hello World")
>>>>>>> You will see there is no error reported.
>>>>>>>
>>>>>>> On the other hand, if you do the same with the command:
>>>>>>> (print (list "Hello World"))
>>>>>>> then you will see the error message:
>>>>>>>
>>>>>>> "Nyquist error returned from Nyquist Prompt:
>>>>>>> ("Hello World")"
>>>>>>>
>>>>>>> The reason that you see the error message in the latter case, is
>>>>>>> because a string list is not defined as a valid return type. Anything
>>>>>>> that is not defined as a valid return type is defined as an error
>>>>>>> type. The change is that the debug window now tells you that Nyquist
>>>>>>> has returned an error type rather than not telling you.
>>>>>>>
>>>>>>> I think the question is whether it is useful for debugging purposes to
>>>>>>> know whether the returned type is a string or an "error" type.
>>>>>>> Previously we have hidden that information.
>>>>>>>
>>>>>>> Steve
>>>>>>>
>>>>>>> On 12 June 2017 at 10:37, Robert Hänggi <[hidden email]>
>>>>>>> wrote:
>>>>>>>> The recently added
>>>>>>>> "Nyquist error returned from Nyquist Prompt:" is imho pretty useless
>>>>>>>> and annoying.
>>>>>>>> This belongs to the title bar if anywhere.
>>>>>>>> There is absolute no error in the code when I simply want to debug a
>>>>>>>> variable or property or some other information.
>>>>>>>> Also, the "Nyquist returned NIL" is still reported in the log file
>>>>>>>> and
>>>>>>>> thus cluttering it unnecessarily.
>>>>>>>>
>>>>>>>> Robert
>>>>>>>>
>>>>>>>> ------------------------------------------------------------------------------
>>>>>>>> Check out the vibrant tech community on one of the world's most
>>>>>>>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>>>>>>>> _______________________________________________
>>>>>>>> Audacity-quality mailing list
>>>>>>>> [hidden email]
>>>>>>>> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>>>>>>>
>>>>>>> ------------------------------------------------------------------------------
>>>>>>> Check out the vibrant tech community on one of the world's most
>>>>>>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>>>>>>> _______________________________________________
>>>>>>> Audacity-quality mailing list
>>>>>>> [hidden email]
>>>>>>> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>>>>>>>
>>>>>>
>>>>>> ------------------------------------------------------------------------------
>>>>>> Check out the vibrant tech community on one of the world's most
>>>>>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>>>>>> _______________________________________________
>>>>>> Audacity-quality mailing list
>>>>>> [hidden email]
>>>>>> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>>>>>
>>>>> ------------------------------------------------------------------------------
>>>>> Check out the vibrant tech community on one of the world's most
>>>>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>>>>> _______________________________________________
>>>>> Audacity-quality mailing list
>>>>> [hidden email]
>>>>> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>>>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>> Check out the vibrant tech community on one of the world's most
>>>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>>>> _______________________________________________
>>>> Audacity-quality mailing list
>>>> [hidden email]
>>>> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>>
>> ------------------------------------------------------------------------------
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> _______________________________________________
>> Audacity-quality mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Audacity-quality mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/audacity-quality

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Audacity-quality mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-quality
Reply | Threaded
Open this post in threaded view
|

Re: Additional message in Debug output

Robert Hänggi
On 13/06/2017, Steve the Fiddle <[hidden email]> wrote:
> Thanks Robert, those plug-ins provide a good example where you want
> the 'side-effects' rather than the return value.

LISP is known as a language of having a lot of side effects and so we
adhere to the tradition
in this case ;)
>
> I don't see that it's a big problem as users are mostly be unaware of
> the log. I agree though that where no return value is expected or
> required, the log message is just clutter, so better if we provide a
> valid means of telling Audacity to "do nothing".
>

+1

> As a point of interest, I tested with tts-end and got the speech
> output working. I had to change Audacity's playback settings, and set
> the sample rate of "phrase" to a supported rate, and then it worked
> perfectly.
>
That's remarkable.

Can you tell me what you did and if the resampling can be automated
somehow (with the help of the available properties, such as the
project rate).
I wonder if we couldn't add a property to *audacity* in order to see
on which OS a plug-in is currently running.
The *file-separator* is not really a elegant way to do it.

On the Audacity4blind list, some Linux users were disappointed that it
only runs on Windows and I therefore provided the additional message
box variant.



> Contrary to what I said previously, I'm now liking your idea of an
> empty string as a "No-Op". It's simple to use, easy to implement, and
> I don't think it's surprising if an empty string does nothing. I can't
> think  of any practical use for displaying an empty string, so I've
> now made that change. Please try it and let me know what you think.
> Note that because it's still a returned string, it behaves like other
> returned strings in that for process type plug-ins, processing stops
> after the first returned result, but in the Nyquist Prompt (and
> non-process types), processing continues for each selected track.
>
Hmpf, not yet fully satisfactory then.
I do in principle agree that for process plug-ins one output is enough.
However, it would be nice if the time of the break could be controlled
by means of the return value.

For instance, your replayGain plug-in does process and analyze audio.
- Help should be displayed on the first track
- Errors likewise
- When Analyze is chosen, the values should be recorded in *scratch*
and returned after analysing the last selected track.

For now, "NIL" is the only way to do it and it will clutter the log.
I've contemplated 't' as a valid "no-op" code but it seems that it is
not a boolean value but rather a symbol (which is by default taken
care of in nyx.c) and is probably not propagated to nyquist.c


> The logic involved handling logging is quite complex, so please test
> as much as you can and let me know if there's any weird behaviour. I
> 'think' it should all be reasonably logical, and hopefully useful.
>
Thanks, I will run some tests and let you know.

Robert

> Steve
>
>
> On 13 June 2017 at 13:31, Robert Hänggi <[hidden email]> wrote:
>> Thanks Steve
>>
>> The plug-ins work again but still with the floor that they are logged
>> as "Warning: Nyquist returned nyx_error." (in most cases not relevant
>> to the user because it's hidden)
>> that's why I said that we need a dummy return as you like to call it.
>>
>> Example: one plug-in reports the selection length.
>> This works even if 10 tracks are selected. The duration does not
>> change and hence it is only spoken on the last track.
>> However, it will produce ten log entries nonetheless because nil is
>> always returned.
>>
>> Here are the plug-ins, if you want to try them on a Windows machine
>> (for audio output).
>> https://www.dropbox.com/s/xzvi08mklgwsd99/tts-suite.zip?dl=1
>>
>> The wav files are mandatory (tts-suite-fast.wav has precedence over
>> tts-suite.wav).
>> Thanks to Robbie Sandberg for his voice performance.
>> The files should directly be installed in the plug-in folder, not in a
>> sub folder of it.
>> After the "tts-xxx.ny" file is enabled in the effect manager, it will
>> be onwards be listed there and in the Analyse menu as "Report xxx".
>> The output goes (presumably) to the standard output of Windows and
>> volume etc have to be changed there.
>>
>> Robert
>>
>> On 13/06/2017, Steve the Fiddle <[hidden email]> wrote:
>>> Perhaps better for you now Robert.
>>>
>>> I was wrong about boolean return values. We don't currently handle
>>> them any differently from other non-valid return types. Changing that
>>> requires modifying files in lib-src so I've left that for now.
>>>
>>> This will all be documented in due course, but briefly:
>>>
>>> When "debugflags" is set to "trace", the debug window will open if
>>> there is anything to show.
>>>
>>> when "debugflags" is set to "notrace", error logging is redirected to
>>> the Audacity log.
>>>
>>> When the Debug button is pressed, the debug window will open
>>> regardless of whether there is anything to show.
>>>
>>> To enable trace without enabling automatic opening of the debug
>>> window, set *tracenable* in the Nyquist code.
>>>
>>> To always open the debug window on error with brief error messages,
>>> set "debugflags" to "trace" and *tracenable* to nil at the top of the
>>> Nyquist code.
>>>
>>> To show text in the debug window without triggering an error and
>>> without requiring the debug button to be pressed, set debugflags to
>>> trace and return a valid data type. An empty string is a valid return
>>> value. Unmodified *track* is a valid return value.
>>>
>>> We don't currently have a "dummy" return value, but we could add one.
>>> I'm not too keen on using an empty string as a dummy, because that
>>> could be confusing when debugging code that should return a message
>>> but due to a bug returns an empty string. A special string value would
>>> be the easiest to implement as a dummy, for example: "*no-print*". Do
>>> we need a dummy return value?
>>>
>>> Steve
>>>
>>>
>>> On 12 June 2017 at 15:02, Steve the Fiddle <[hidden email]>
>>> wrote:
>>>> From a debugging point of view, which is after all the purpose of the
>>>> debug window, it would probably be most useful to report boolean
>>>> return values.
>>>>
>>>> Steve
>>>>
>>>> On 12 June 2017 at 14:39, Robert Hänggi <[hidden email]> wrote:
>>>>> Treating NIL as valid is probably fine although a bit
>>>>> counter-intuitive (from a C point of view)
>>>>> It would at least free me from introducing a version control 2.1.3 vs
>>>>> 2.2.0.
>>>>> What about a returned value of 't' (true) shouldn't that be treated
>>>>> specially too?
>>>>>
>>>>> Robert
>>>>>
>>>>> On 12/06/2017, Steve the Fiddle <[hidden email]> wrote:
>>>>>> On 12 June 2017 at 12:19, Robert Hänggi <[hidden email]>
>>>>>> wrote:
>>>>>>> Thanks for replying Steve.
>>>>>>> I find the message itself superfluous (in the debug multi-line pane).
>>>>>>> As I said, it could go to the title.
>>>>>>
>>>>>> Not really, because the debug window does not necessarily return
>>>>>> "errors". It would be wrong for the debug window to be titled as an
>>>>>> error output if it only contained non-error debug "information".
>>>>>>
>>>>>> On the other hand, the debug window could include error messages and
>>>>>> still have a valid return value. Unless we parse the entire debug
>>>>>> output we don't know if the debug information includes errors, but we
>>>>>> do know if the returned value is a valid type.
>>>>>>
>>>>>>
>>>>>>> The message should imply that no valid output has been returned,
>>>>>>> rather than saying that it was an error.
>>>>>>
>>>>>> The message is triggered when the returned value == nyx_error
>>>>>>
>>>>>>>
>>>>>>> It is in general nice that the debug output opens automatically on
>>>>>>> raised errors.
>>>>>>> That's very handy for plug-ins without GUI.
>>>>>>
>>>>>> That's the idea.
>>>>>> We don't however want to automatically open the debug window for
>>>>>> non-error debug information that Nyquist may return.
>>>>>>
>>>>>>>
>>>>>>> What I would like to have is:
>>>>>>> - A facility to turn the debug window off in absolute terms, even if
>>>>>>> mDebugOutput (nyquist.cpp) is not empty, i.e. another switch for
>>>>>>> debugflags.
>>>>>>> - Not to display an empty debug window when the return value is NIL
>>>>>>> or
>>>>>>> rather to define a valid dummy return (see below).
>>>>>>
>>>>>> It would be possible to provide a flag that completely disables debug
>>>>>> output, but I'm not sure that will do what you want. We shouldn't rely
>>>>>> on "errors" to perform the actions that we require. I'm -1 for
>>>>>> building on bugs.
>>>>>>
>>>>>>>
>>>>>>> The problem I'm facing is the following:
>>>>>>> I have a bunch of 15 plug-ins that are self-voiced.
>>>>>>> They report all kind of things such as Peak, Rms, Gain, Frequency,
>>>>>>> Tempo and so on.
>>>>>>> On Linux and Mac, the information is returned as message box.
>>>>>>> However, on Windows it is returned as natural speech.
>>>>>>
>>>>>> How are you doing that? If you return text from the plug-in it should
>>>>>> be displayed as an accessible text message (and no error). Does that
>>>>>> not happen?
>>>>>>
>>>>>>>
>>>>>>> Your changes do that
>>>>>>> 1. the debug window opens automatically
>>>>>>> 2. the warning "Nyquist returned NIL" is logged.
>>>>>>
>>>>>> That's a debug message that lets plug-in developers know that their
>>>>>> plug-in returned nil, which can be important information for
>>>>>> debugging. I agree that "nil" should not be treated as an error,
>>>>>> because we explicitly handle it as a return value.
>>>>>>
>>>>>> Steve
>>>>>>
>>>>>>> I can't produce an artificial output because this would defeat the
>>>>>>> purpose of the plug-ins since an message box would appear.
>>>>>>> A good solution would be that an empty string ("") as last statement
>>>>>>> is a valid return possibility and it would neither trigger a message
>>>>>>> box nor a log entry.
>>>>>>> In this fashion, NIL could still raise an error and thus indicate a
>>>>>>> problem with the code.
>>>>>>> You can see it likewise as a kind of "Skip processing this track"
>>>>>>> For instance:
>>>>>>> (if (soundp *track*)
>>>>>>>     do something
>>>>>>> ;else
>>>>>>> "")
>>>>>>>
>>>>>>> In other words, process only mono tracks that are selected.
>>>>>>>
>>>>>>> Robert
>>>>>>>
>>>>>>>
>>>>>>> On 12/06/2017, Steve the Fiddle <[hidden email]> wrote:
>>>>>>>> I am considering removing that as I agree it does not appear to be
>>>>>>>> very useful, but it does provide information about what Nyquist is
>>>>>>>> doing that is not otherwise available.
>>>>>>>>
>>>>>>>> If, for example, you view the debug output from the Nyquist Prompt
>>>>>>>> from the command:
>>>>>>>> (print "Hello World")
>>>>>>>> You will see there is no error reported.
>>>>>>>>
>>>>>>>> On the other hand, if you do the same with the command:
>>>>>>>> (print (list "Hello World"))
>>>>>>>> then you will see the error message:
>>>>>>>>
>>>>>>>> "Nyquist error returned from Nyquist Prompt:
>>>>>>>> ("Hello World")"
>>>>>>>>
>>>>>>>> The reason that you see the error message in the latter case, is
>>>>>>>> because a string list is not defined as a valid return type.
>>>>>>>> Anything
>>>>>>>> that is not defined as a valid return type is defined as an error
>>>>>>>> type. The change is that the debug window now tells you that Nyquist
>>>>>>>> has returned an error type rather than not telling you.
>>>>>>>>
>>>>>>>> I think the question is whether it is useful for debugging purposes
>>>>>>>> to
>>>>>>>> know whether the returned type is a string or an "error" type.
>>>>>>>> Previously we have hidden that information.
>>>>>>>>
>>>>>>>> Steve
>>>>>>>>
>>>>>>>> On 12 June 2017 at 10:37, Robert Hänggi <[hidden email]>
>>>>>>>> wrote:
>>>>>>>>> The recently added
>>>>>>>>> "Nyquist error returned from Nyquist Prompt:" is imho pretty
>>>>>>>>> useless
>>>>>>>>> and annoying.
>>>>>>>>> This belongs to the title bar if anywhere.
>>>>>>>>> There is absolute no error in the code when I simply want to debug
>>>>>>>>> a
>>>>>>>>> variable or property or some other information.
>>>>>>>>> Also, the "Nyquist returned NIL" is still reported in the log file
>>>>>>>>> and
>>>>>>>>> thus cluttering it unnecessarily.
>>>>>>>>>
>>>>>>>>> Robert
>>>>>>>>>
>>>>>>>>> ------------------------------------------------------------------------------
>>>>>>>>> Check out the vibrant tech community on one of the world's most
>>>>>>>>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>>>>>>>>> _______________________________________________
>>>>>>>>> Audacity-quality mailing list
>>>>>>>>> [hidden email]
>>>>>>>>> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>>>>>>>>
>>>>>>>> ------------------------------------------------------------------------------
>>>>>>>> Check out the vibrant tech community on one of the world's most
>>>>>>>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>>>>>>>> _______________________________________________
>>>>>>>> Audacity-quality mailing list
>>>>>>>> [hidden email]
>>>>>>>> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>>>>>>>>
>>>>>>>
>>>>>>> ------------------------------------------------------------------------------
>>>>>>> Check out the vibrant tech community on one of the world's most
>>>>>>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>>>>>>> _______________________________________________
>>>>>>> Audacity-quality mailing list
>>>>>>> [hidden email]
>>>>>>> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>>>>>>
>>>>>> ------------------------------------------------------------------------------
>>>>>> Check out the vibrant tech community on one of the world's most
>>>>>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>>>>>> _______________________________________________
>>>>>> Audacity-quality mailing list
>>>>>> [hidden email]
>>>>>> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>>>>>>
>>>>>
>>>>> ------------------------------------------------------------------------------
>>>>> Check out the vibrant tech community on one of the world's most
>>>>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>>>>> _______________________________________________
>>>>> Audacity-quality mailing list
>>>>> [hidden email]
>>>>> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>>>
>>> ------------------------------------------------------------------------------
>>> Check out the vibrant tech community on one of the world's most
>>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>>> _______________________________________________
>>> Audacity-quality mailing list
>>> [hidden email]
>>> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>>>
>>
>> ------------------------------------------------------------------------------
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> _______________________________________________
>> Audacity-quality mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Audacity-quality mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Audacity-quality mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-quality
Reply | Threaded
Open this post in threaded view
|

Re: Additional message in Debug output

Stevethefiddle
On 14 June 2017 at 11:33, Robert Hänggi <[hidden email]> wrote:
> On 13/06/2017, Steve the Fiddle <[hidden email]> wrote:
>> Thanks Robert, those plug-ins provide a good example where you want
>> the 'side-effects' rather than the return value.
>
> LISP is known as a language of having a lot of side effects and so we
> adhere to the tradition
> in this case ;)

Yes.

>>
>> I don't see that it's a big problem as users are mostly be unaware of
>> the log. I agree though that where no return value is expected or
>> required, the log message is just clutter, so better if we provide a
>> valid means of telling Audacity to "do nothing".
>>
>
> +1
>
>> As a point of interest, I tested with tts-end and got the speech
>> output working. I had to change Audacity's playback settings, and set
>> the sample rate of "phrase" to a supported rate, and then it worked
>> perfectly.
>>
> That's remarkable.
>
> Can you tell me what you did and if the resampling can be automated
> somehow (with the help of the available properties, such as the
> project rate).

Quite simple in the end.
Nyquist (on Linux) did not like playing audio that had a sample rate
of 20506.5 Hz (0.93 * 22050) and reported the error:

"warning: could not open audio, error -9997, Invalid sample rate."

So I just wrapped it in (force-srate 44100 ...

like this:

(s-save (force-srate 44100 (scale-srate (scale-db -6  phrase) 0.93))
ny:all "" :play t) "")))))

The other thing that I needed to do was to set the output device for
Audacity to the "hd" option. This uses the ALSA drivers directly,
bypassing PulseAudio. I don't think that Nyquist supports PulseAudio
yet, but the ALSA drivers do not provide software mixing or
resampling, so it is essential that no other applications are
accessing the sound card, and that the sample rate is supported by the
hardware.

A common "gotcha" when using ALSA directly is that web browser
plug-ins can hang onto the audio device even when not playing media,
and in some cases, even when there is no sign of media being played
(Adobe Flash was terrible for this at one time, but seems a little
better behaved these days).

> I wonder if we couldn't add a property to *audacity* in order to see
> on which OS a plug-in is currently running.
> The *file-separator* is not really a elegant way to do it.

The best solution to this problem would be to add PulseAudio support
to Nyquist, but I've no idea how to do that. PulseAudio is the default
sound server for most modern Desktop Linux distributions.

Some Linux distributions that are designed primarily for media
production use Jack Audio System as the default, so ideally it would
be nice to also have Jack support.

>
> On the Audacity4blind list, some Linux users were disappointed that it
> only runs on Windows and I therefore provided the additional message
> box variant.

On Linux, I think the above should work reliably, though it may be
necessary for the user to log out and back in again if any
applications have claimed access to the sound card.

I've not yet tested on Mac but intend to do so.

>
>
>
>> Contrary to what I said previously, I'm now liking your idea of an
>> empty string as a "No-Op". It's simple to use, easy to implement, and
>> I don't think it's surprising if an empty string does nothing. I can't
>> think  of any practical use for displaying an empty string, so I've
>> now made that change. Please try it and let me know what you think.
>> Note that because it's still a returned string, it behaves like other
>> returned strings in that for process type plug-ins, processing stops
>> after the first returned result, but in the Nyquist Prompt (and
>> non-process types), processing continues for each selected track.
>>
> Hmpf, not yet fully satisfactory then.
> I do in principle agree that for process plug-ins one output is enough.
> However, it would be nice if the time of the break could be controlled
> by means of the return value.
>
> For instance, your replayGain plug-in does process and analyze audio.
> - Help should be displayed on the first track
> - Errors likewise
> - When Analyze is chosen, the values should be recorded in *scratch*
> and returned after analysing the last selected track.
>
> For now, "NIL" is the only way to do it and it will clutter the log.
> I've contemplated 't' as a valid "no-op" code but it seems that it is
> not a boolean value but rather a symbol (which is by default taken
> care of in nyx.c) and is probably not propagated to nyquist.c

In theory we should be able to define additional data types which
trigger or control other types of behaviour in Audacity (including
No-Op), but that's not a direction that I want to go at this time.
More likely in the future, Nyquist will call for samples from Audacity
rather than being passed tracks. This would allow Nyquist to handle
data from multiple tracks simultaneously (rather than being limited to
sequential track processing), allow us to process extremely long
tracks by grabbing buffers, and access audio that is outside of the
current selection.

>
>
>> The logic involved handling logging is quite complex, so please test
>> as much as you can and let me know if there's any weird behaviour. I
>> 'think' it should all be reasonably logical, and hopefully useful.
>>
> Thanks, I will run some tests and let you know.

Thanks,

Steve

>
> Robert
>> Steve
>>
>>
>> On 13 June 2017 at 13:31, Robert Hänggi <[hidden email]> wrote:
>>> Thanks Steve
>>>
>>> The plug-ins work again but still with the floor that they are logged
>>> as "Warning: Nyquist returned nyx_error." (in most cases not relevant
>>> to the user because it's hidden)
>>> that's why I said that we need a dummy return as you like to call it.
>>>
>>> Example: one plug-in reports the selection length.
>>> This works even if 10 tracks are selected. The duration does not
>>> change and hence it is only spoken on the last track.
>>> However, it will produce ten log entries nonetheless because nil is
>>> always returned.
>>>
>>> Here are the plug-ins, if you want to try them on a Windows machine
>>> (for audio output).
>>> https://www.dropbox.com/s/xzvi08mklgwsd99/tts-suite.zip?dl=1
>>>
>>> The wav files are mandatory (tts-suite-fast.wav has precedence over
>>> tts-suite.wav).
>>> Thanks to Robbie Sandberg for his voice performance.
>>> The files should directly be installed in the plug-in folder, not in a
>>> sub folder of it.
>>> After the "tts-xxx.ny" file is enabled in the effect manager, it will
>>> be onwards be listed there and in the Analyse menu as "Report xxx".
>>> The output goes (presumably) to the standard output of Windows and
>>> volume etc have to be changed there.
>>>
>>> Robert
>>>
>>> On 13/06/2017, Steve the Fiddle <[hidden email]> wrote:
>>>> Perhaps better for you now Robert.
>>>>
>>>> I was wrong about boolean return values. We don't currently handle
>>>> them any differently from other non-valid return types. Changing that
>>>> requires modifying files in lib-src so I've left that for now.
>>>>
>>>> This will all be documented in due course, but briefly:
>>>>
>>>> When "debugflags" is set to "trace", the debug window will open if
>>>> there is anything to show.
>>>>
>>>> when "debugflags" is set to "notrace", error logging is redirected to
>>>> the Audacity log.
>>>>
>>>> When the Debug button is pressed, the debug window will open
>>>> regardless of whether there is anything to show.
>>>>
>>>> To enable trace without enabling automatic opening of the debug
>>>> window, set *tracenable* in the Nyquist code.
>>>>
>>>> To always open the debug window on error with brief error messages,
>>>> set "debugflags" to "trace" and *tracenable* to nil at the top of the
>>>> Nyquist code.
>>>>
>>>> To show text in the debug window without triggering an error and
>>>> without requiring the debug button to be pressed, set debugflags to
>>>> trace and return a valid data type. An empty string is a valid return
>>>> value. Unmodified *track* is a valid return value.
>>>>
>>>> We don't currently have a "dummy" return value, but we could add one.
>>>> I'm not too keen on using an empty string as a dummy, because that
>>>> could be confusing when debugging code that should return a message
>>>> but due to a bug returns an empty string. A special string value would
>>>> be the easiest to implement as a dummy, for example: "*no-print*". Do
>>>> we need a dummy return value?
>>>>
>>>> Steve
>>>>
>>>>
>>>> On 12 June 2017 at 15:02, Steve the Fiddle <[hidden email]>
>>>> wrote:
>>>>> From a debugging point of view, which is after all the purpose of the
>>>>> debug window, it would probably be most useful to report boolean
>>>>> return values.
>>>>>
>>>>> Steve
>>>>>
>>>>> On 12 June 2017 at 14:39, Robert Hänggi <[hidden email]> wrote:
>>>>>> Treating NIL as valid is probably fine although a bit
>>>>>> counter-intuitive (from a C point of view)
>>>>>> It would at least free me from introducing a version control 2.1.3 vs
>>>>>> 2.2.0.
>>>>>> What about a returned value of 't' (true) shouldn't that be treated
>>>>>> specially too?
>>>>>>
>>>>>> Robert
>>>>>>
>>>>>> On 12/06/2017, Steve the Fiddle <[hidden email]> wrote:
>>>>>>> On 12 June 2017 at 12:19, Robert Hänggi <[hidden email]>
>>>>>>> wrote:
>>>>>>>> Thanks for replying Steve.
>>>>>>>> I find the message itself superfluous (in the debug multi-line pane).
>>>>>>>> As I said, it could go to the title.
>>>>>>>
>>>>>>> Not really, because the debug window does not necessarily return
>>>>>>> "errors". It would be wrong for the debug window to be titled as an
>>>>>>> error output if it only contained non-error debug "information".
>>>>>>>
>>>>>>> On the other hand, the debug window could include error messages and
>>>>>>> still have a valid return value. Unless we parse the entire debug
>>>>>>> output we don't know if the debug information includes errors, but we
>>>>>>> do know if the returned value is a valid type.
>>>>>>>
>>>>>>>
>>>>>>>> The message should imply that no valid output has been returned,
>>>>>>>> rather than saying that it was an error.
>>>>>>>
>>>>>>> The message is triggered when the returned value == nyx_error
>>>>>>>
>>>>>>>>
>>>>>>>> It is in general nice that the debug output opens automatically on
>>>>>>>> raised errors.
>>>>>>>> That's very handy for plug-ins without GUI.
>>>>>>>
>>>>>>> That's the idea.
>>>>>>> We don't however want to automatically open the debug window for
>>>>>>> non-error debug information that Nyquist may return.
>>>>>>>
>>>>>>>>
>>>>>>>> What I would like to have is:
>>>>>>>> - A facility to turn the debug window off in absolute terms, even if
>>>>>>>> mDebugOutput (nyquist.cpp) is not empty, i.e. another switch for
>>>>>>>> debugflags.
>>>>>>>> - Not to display an empty debug window when the return value is NIL
>>>>>>>> or
>>>>>>>> rather to define a valid dummy return (see below).
>>>>>>>
>>>>>>> It would be possible to provide a flag that completely disables debug
>>>>>>> output, but I'm not sure that will do what you want. We shouldn't rely
>>>>>>> on "errors" to perform the actions that we require. I'm -1 for
>>>>>>> building on bugs.
>>>>>>>
>>>>>>>>
>>>>>>>> The problem I'm facing is the following:
>>>>>>>> I have a bunch of 15 plug-ins that are self-voiced.
>>>>>>>> They report all kind of things such as Peak, Rms, Gain, Frequency,
>>>>>>>> Tempo and so on.
>>>>>>>> On Linux and Mac, the information is returned as message box.
>>>>>>>> However, on Windows it is returned as natural speech.
>>>>>>>
>>>>>>> How are you doing that? If you return text from the plug-in it should
>>>>>>> be displayed as an accessible text message (and no error). Does that
>>>>>>> not happen?
>>>>>>>
>>>>>>>>
>>>>>>>> Your changes do that
>>>>>>>> 1. the debug window opens automatically
>>>>>>>> 2. the warning "Nyquist returned NIL" is logged.
>>>>>>>
>>>>>>> That's a debug message that lets plug-in developers know that their
>>>>>>> plug-in returned nil, which can be important information for
>>>>>>> debugging. I agree that "nil" should not be treated as an error,
>>>>>>> because we explicitly handle it as a return value.
>>>>>>>
>>>>>>> Steve
>>>>>>>
>>>>>>>> I can't produce an artificial output because this would defeat the
>>>>>>>> purpose of the plug-ins since an message box would appear.
>>>>>>>> A good solution would be that an empty string ("") as last statement
>>>>>>>> is a valid return possibility and it would neither trigger a message
>>>>>>>> box nor a log entry.
>>>>>>>> In this fashion, NIL could still raise an error and thus indicate a
>>>>>>>> problem with the code.
>>>>>>>> You can see it likewise as a kind of "Skip processing this track"
>>>>>>>> For instance:
>>>>>>>> (if (soundp *track*)
>>>>>>>>     do something
>>>>>>>> ;else
>>>>>>>> "")
>>>>>>>>
>>>>>>>> In other words, process only mono tracks that are selected.
>>>>>>>>
>>>>>>>> Robert
>>>>>>>>
>>>>>>>>
>>>>>>>> On 12/06/2017, Steve the Fiddle <[hidden email]> wrote:
>>>>>>>>> I am considering removing that as I agree it does not appear to be
>>>>>>>>> very useful, but it does provide information about what Nyquist is
>>>>>>>>> doing that is not otherwise available.
>>>>>>>>>
>>>>>>>>> If, for example, you view the debug output from the Nyquist Prompt
>>>>>>>>> from the command:
>>>>>>>>> (print "Hello World")
>>>>>>>>> You will see there is no error reported.
>>>>>>>>>
>>>>>>>>> On the other hand, if you do the same with the command:
>>>>>>>>> (print (list "Hello World"))
>>>>>>>>> then you will see the error message:
>>>>>>>>>
>>>>>>>>> "Nyquist error returned from Nyquist Prompt:
>>>>>>>>> ("Hello World")"
>>>>>>>>>
>>>>>>>>> The reason that you see the error message in the latter case, is
>>>>>>>>> because a string list is not defined as a valid return type.
>>>>>>>>> Anything
>>>>>>>>> that is not defined as a valid return type is defined as an error
>>>>>>>>> type. The change is that the debug window now tells you that Nyquist
>>>>>>>>> has returned an error type rather than not telling you.
>>>>>>>>>
>>>>>>>>> I think the question is whether it is useful for debugging purposes
>>>>>>>>> to
>>>>>>>>> know whether the returned type is a string or an "error" type.
>>>>>>>>> Previously we have hidden that information.
>>>>>>>>>
>>>>>>>>> Steve
>>>>>>>>>
>>>>>>>>> On 12 June 2017 at 10:37, Robert Hänggi <[hidden email]>
>>>>>>>>> wrote:
>>>>>>>>>> The recently added
>>>>>>>>>> "Nyquist error returned from Nyquist Prompt:" is imho pretty
>>>>>>>>>> useless
>>>>>>>>>> and annoying.
>>>>>>>>>> This belongs to the title bar if anywhere.
>>>>>>>>>> There is absolute no error in the code when I simply want to debug
>>>>>>>>>> a
>>>>>>>>>> variable or property or some other information.
>>>>>>>>>> Also, the "Nyquist returned NIL" is still reported in the log file
>>>>>>>>>> and
>>>>>>>>>> thus cluttering it unnecessarily.
>>>>>>>>>>
>>>>>>>>>> Robert
>>>>>>>>>>
>>>>>>>>>> ------------------------------------------------------------------------------
>>>>>>>>>> Check out the vibrant tech community on one of the world's most
>>>>>>>>>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>>>>>>>>>> _______________________________________________
>>>>>>>>>> Audacity-quality mailing list
>>>>>>>>>> [hidden email]
>>>>>>>>>> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>>>>>>>>>
>>>>>>>>> ------------------------------------------------------------------------------
>>>>>>>>> Check out the vibrant tech community on one of the world's most
>>>>>>>>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>>>>>>>>> _______________________________________________
>>>>>>>>> Audacity-quality mailing list
>>>>>>>>> [hidden email]
>>>>>>>>> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>>>>>>>>>
>>>>>>>>
>>>>>>>> ------------------------------------------------------------------------------
>>>>>>>> Check out the vibrant tech community on one of the world's most
>>>>>>>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>>>>>>>> _______________________________________________
>>>>>>>> Audacity-quality mailing list
>>>>>>>> [hidden email]
>>>>>>>> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>>>>>>>
>>>>>>> ------------------------------------------------------------------------------
>>>>>>> Check out the vibrant tech community on one of the world's most
>>>>>>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>>>>>>> _______________________________________________
>>>>>>> Audacity-quality mailing list
>>>>>>> [hidden email]
>>>>>>> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>>>>>>>
>>>>>>
>>>>>> ------------------------------------------------------------------------------
>>>>>> Check out the vibrant tech community on one of the world's most
>>>>>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>>>>>> _______________________________________________
>>>>>> Audacity-quality mailing list
>>>>>> [hidden email]
>>>>>> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>>>>
>>>> ------------------------------------------------------------------------------
>>>> Check out the vibrant tech community on one of the world's most
>>>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>>>> _______________________________________________
>>>> Audacity-quality mailing list
>>>> [hidden email]
>>>> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Check out the vibrant tech community on one of the world's most
>>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>>> _______________________________________________
>>> Audacity-quality mailing list
>>> [hidden email]
>>> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>>
>> ------------------------------------------------------------------------------
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> _______________________________________________
>> Audacity-quality mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Audacity-quality mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/audacity-quality

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Audacity-quality mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-quality
Reply | Threaded
Open this post in threaded view
|

Re: Additional message in Debug output

Robert Hänggi
I don't know if the Orca screen reader will still work when the user
switches to Alsa e.g. if it tries to report the progress bar or
something while Alsa is accessed.
I've only a Linux virtual machine installed and the screen reader
hangs on launching Audacity. This was to be expected I think due to
the audio driver emulation.

Robert

On 14/06/2017, Steve the Fiddle <[hidden email]> wrote:

> On 14 June 2017 at 11:33, Robert Hänggi <[hidden email]> wrote:
>> On 13/06/2017, Steve the Fiddle <[hidden email]> wrote:
>>> Thanks Robert, those plug-ins provide a good example where you want
>>> the 'side-effects' rather than the return value.
>>
>> LISP is known as a language of having a lot of side effects and so we
>> adhere to the tradition
>> in this case ;)
>
> Yes.
>
>>>
>>> I don't see that it's a big problem as users are mostly be unaware of
>>> the log. I agree though that where no return value is expected or
>>> required, the log message is just clutter, so better if we provide a
>>> valid means of telling Audacity to "do nothing".
>>>
>>
>> +1
>>
>>> As a point of interest, I tested with tts-end and got the speech
>>> output working. I had to change Audacity's playback settings, and set
>>> the sample rate of "phrase" to a supported rate, and then it worked
>>> perfectly.
>>>
>> That's remarkable.
>>
>> Can you tell me what you did and if the resampling can be automated
>> somehow (with the help of the available properties, such as the
>> project rate).
>
> Quite simple in the end.
> Nyquist (on Linux) did not like playing audio that had a sample rate
> of 20506.5 Hz (0.93 * 22050) and reported the error:
>
> "warning: could not open audio, error -9997, Invalid sample rate."
>
> So I just wrapped it in (force-srate 44100 ...
>
> like this:
>
> (s-save (force-srate 44100 (scale-srate (scale-db -6  phrase) 0.93))
> ny:all "" :play t) "")))))
>
> The other thing that I needed to do was to set the output device for
> Audacity to the "hd" option. This uses the ALSA drivers directly,
> bypassing PulseAudio. I don't think that Nyquist supports PulseAudio
> yet, but the ALSA drivers do not provide software mixing or
> resampling, so it is essential that no other applications are
> accessing the sound card, and that the sample rate is supported by the
> hardware.
>
> A common "gotcha" when using ALSA directly is that web browser
> plug-ins can hang onto the audio device even when not playing media,
> and in some cases, even when there is no sign of media being played
> (Adobe Flash was terrible for this at one time, but seems a little
> better behaved these days).
>
>> I wonder if we couldn't add a property to *audacity* in order to see
>> on which OS a plug-in is currently running.
>> The *file-separator* is not really a elegant way to do it.
>
> The best solution to this problem would be to add PulseAudio support
> to Nyquist, but I've no idea how to do that. PulseAudio is the default
> sound server for most modern Desktop Linux distributions.
>
> Some Linux distributions that are designed primarily for media
> production use Jack Audio System as the default, so ideally it would
> be nice to also have Jack support.
>
>>
>> On the Audacity4blind list, some Linux users were disappointed that it
>> only runs on Windows and I therefore provided the additional message
>> box variant.
>
> On Linux, I think the above should work reliably, though it may be
> necessary for the user to log out and back in again if any
> applications have claimed access to the sound card.
>
> I've not yet tested on Mac but intend to do so.
>
>>
>>
>>
>>> Contrary to what I said previously, I'm now liking your idea of an
>>> empty string as a "No-Op". It's simple to use, easy to implement, and
>>> I don't think it's surprising if an empty string does nothing. I can't
>>> think  of any practical use for displaying an empty string, so I've
>>> now made that change. Please try it and let me know what you think.
>>> Note that because it's still a returned string, it behaves like other
>>> returned strings in that for process type plug-ins, processing stops
>>> after the first returned result, but in the Nyquist Prompt (and
>>> non-process types), processing continues for each selected track.
>>>
>> Hmpf, not yet fully satisfactory then.
>> I do in principle agree that for process plug-ins one output is enough.
>> However, it would be nice if the time of the break could be controlled
>> by means of the return value.
>>
>> For instance, your replayGain plug-in does process and analyze audio.
>> - Help should be displayed on the first track
>> - Errors likewise
>> - When Analyze is chosen, the values should be recorded in *scratch*
>> and returned after analysing the last selected track.
>>
>> For now, "NIL" is the only way to do it and it will clutter the log.
>> I've contemplated 't' as a valid "no-op" code but it seems that it is
>> not a boolean value but rather a symbol (which is by default taken
>> care of in nyx.c) and is probably not propagated to nyquist.c
>
> In theory we should be able to define additional data types which
> trigger or control other types of behaviour in Audacity (including
> No-Op), but that's not a direction that I want to go at this time.
> More likely in the future, Nyquist will call for samples from Audacity
> rather than being passed tracks. This would allow Nyquist to handle
> data from multiple tracks simultaneously (rather than being limited to
> sequential track processing), allow us to process extremely long
> tracks by grabbing buffers, and access audio that is outside of the
> current selection.
>
>>
>>
>>> The logic involved handling logging is quite complex, so please test
>>> as much as you can and let me know if there's any weird behaviour. I
>>> 'think' it should all be reasonably logical, and hopefully useful.
>>>
>> Thanks, I will run some tests and let you know.
>
> Thanks,
>
> Steve
>
>>
>> Robert
>>> Steve
>>>
>>>
>>> On 13 June 2017 at 13:31, Robert Hänggi <[hidden email]> wrote:
>>>> Thanks Steve
>>>>
>>>> The plug-ins work again but still with the floor that they are logged
>>>> as "Warning: Nyquist returned nyx_error." (in most cases not relevant
>>>> to the user because it's hidden)
>>>> that's why I said that we need a dummy return as you like to call it.
>>>>
>>>> Example: one plug-in reports the selection length.
>>>> This works even if 10 tracks are selected. The duration does not
>>>> change and hence it is only spoken on the last track.
>>>> However, it will produce ten log entries nonetheless because nil is
>>>> always returned.
>>>>
>>>> Here are the plug-ins, if you want to try them on a Windows machine
>>>> (for audio output).
>>>> https://www.dropbox.com/s/xzvi08mklgwsd99/tts-suite.zip?dl=1
>>>>
>>>> The wav files are mandatory (tts-suite-fast.wav has precedence over
>>>> tts-suite.wav).
>>>> Thanks to Robbie Sandberg for his voice performance.
>>>> The files should directly be installed in the plug-in folder, not in a
>>>> sub folder of it.
>>>> After the "tts-xxx.ny" file is enabled in the effect manager, it will
>>>> be onwards be listed there and in the Analyse menu as "Report xxx".
>>>> The output goes (presumably) to the standard output of Windows and
>>>> volume etc have to be changed there.
>>>>
>>>> Robert
>>>>
>>>> On 13/06/2017, Steve the Fiddle <[hidden email]> wrote:
>>>>> Perhaps better for you now Robert.
>>>>>
>>>>> I was wrong about boolean return values. We don't currently handle
>>>>> them any differently from other non-valid return types. Changing that
>>>>> requires modifying files in lib-src so I've left that for now.
>>>>>
>>>>> This will all be documented in due course, but briefly:
>>>>>
>>>>> When "debugflags" is set to "trace", the debug window will open if
>>>>> there is anything to show.
>>>>>
>>>>> when "debugflags" is set to "notrace", error logging is redirected to
>>>>> the Audacity log.
>>>>>
>>>>> When the Debug button is pressed, the debug window will open
>>>>> regardless of whether there is anything to show.
>>>>>
>>>>> To enable trace without enabling automatic opening of the debug
>>>>> window, set *tracenable* in the Nyquist code.
>>>>>
>>>>> To always open the debug window on error with brief error messages,
>>>>> set "debugflags" to "trace" and *tracenable* to nil at the top of the
>>>>> Nyquist code.
>>>>>
>>>>> To show text in the debug window without triggering an error and
>>>>> without requiring the debug button to be pressed, set debugflags to
>>>>> trace and return a valid data type. An empty string is a valid return
>>>>> value. Unmodified *track* is a valid return value.
>>>>>
>>>>> We don't currently have a "dummy" return value, but we could add one.
>>>>> I'm not too keen on using an empty string as a dummy, because that
>>>>> could be confusing when debugging code that should return a message
>>>>> but due to a bug returns an empty string. A special string value would
>>>>> be the easiest to implement as a dummy, for example: "*no-print*". Do
>>>>> we need a dummy return value?
>>>>>
>>>>> Steve
>>>>>
>>>>>
>>>>> On 12 June 2017 at 15:02, Steve the Fiddle <[hidden email]>
>>>>> wrote:
>>>>>> From a debugging point of view, which is after all the purpose of the
>>>>>> debug window, it would probably be most useful to report boolean
>>>>>> return values.
>>>>>>
>>>>>> Steve
>>>>>>
>>>>>> On 12 June 2017 at 14:39, Robert Hänggi <[hidden email]>
>>>>>> wrote:
>>>>>>> Treating NIL as valid is probably fine although a bit
>>>>>>> counter-intuitive (from a C point of view)
>>>>>>> It would at least free me from introducing a version control 2.1.3 vs
>>>>>>> 2.2.0.
>>>>>>> What about a returned value of 't' (true) shouldn't that be treated
>>>>>>> specially too?
>>>>>>>
>>>>>>> Robert
>>>>>>>
>>>>>>> On 12/06/2017, Steve the Fiddle <[hidden email]> wrote:
>>>>>>>> On 12 June 2017 at 12:19, Robert Hänggi <[hidden email]>
>>>>>>>> wrote:
>>>>>>>>> Thanks for replying Steve.
>>>>>>>>> I find the message itself superfluous (in the debug multi-line
>>>>>>>>> pane).
>>>>>>>>> As I said, it could go to the title.
>>>>>>>>
>>>>>>>> Not really, because the debug window does not necessarily return
>>>>>>>> "errors". It would be wrong for the debug window to be titled as an
>>>>>>>> error output if it only contained non-error debug "information".
>>>>>>>>
>>>>>>>> On the other hand, the debug window could include error messages and
>>>>>>>> still have a valid return value. Unless we parse the entire debug
>>>>>>>> output we don't know if the debug information includes errors, but
>>>>>>>> we
>>>>>>>> do know if the returned value is a valid type.
>>>>>>>>
>>>>>>>>
>>>>>>>>> The message should imply that no valid output has been returned,
>>>>>>>>> rather than saying that it was an error.
>>>>>>>>
>>>>>>>> The message is triggered when the returned value == nyx_error
>>>>>>>>
>>>>>>>>>
>>>>>>>>> It is in general nice that the debug output opens automatically on
>>>>>>>>> raised errors.
>>>>>>>>> That's very handy for plug-ins without GUI.
>>>>>>>>
>>>>>>>> That's the idea.
>>>>>>>> We don't however want to automatically open the debug window for
>>>>>>>> non-error debug information that Nyquist may return.
>>>>>>>>
>>>>>>>>>
>>>>>>>>> What I would like to have is:
>>>>>>>>> - A facility to turn the debug window off in absolute terms, even
>>>>>>>>> if
>>>>>>>>> mDebugOutput (nyquist.cpp) is not empty, i.e. another switch for
>>>>>>>>> debugflags.
>>>>>>>>> - Not to display an empty debug window when the return value is NIL
>>>>>>>>> or
>>>>>>>>> rather to define a valid dummy return (see below).
>>>>>>>>
>>>>>>>> It would be possible to provide a flag that completely disables
>>>>>>>> debug
>>>>>>>> output, but I'm not sure that will do what you want. We shouldn't
>>>>>>>> rely
>>>>>>>> on "errors" to perform the actions that we require. I'm -1 for
>>>>>>>> building on bugs.
>>>>>>>>
>>>>>>>>>
>>>>>>>>> The problem I'm facing is the following:
>>>>>>>>> I have a bunch of 15 plug-ins that are self-voiced.
>>>>>>>>> They report all kind of things such as Peak, Rms, Gain, Frequency,
>>>>>>>>> Tempo and so on.
>>>>>>>>> On Linux and Mac, the information is returned as message box.
>>>>>>>>> However, on Windows it is returned as natural speech.
>>>>>>>>
>>>>>>>> How are you doing that? If you return text from the plug-in it
>>>>>>>> should
>>>>>>>> be displayed as an accessible text message (and no error). Does that
>>>>>>>> not happen?
>>>>>>>>
>>>>>>>>>
>>>>>>>>> Your changes do that
>>>>>>>>> 1. the debug window opens automatically
>>>>>>>>> 2. the warning "Nyquist returned NIL" is logged.
>>>>>>>>
>>>>>>>> That's a debug message that lets plug-in developers know that their
>>>>>>>> plug-in returned nil, which can be important information for
>>>>>>>> debugging. I agree that "nil" should not be treated as an error,
>>>>>>>> because we explicitly handle it as a return value.
>>>>>>>>
>>>>>>>> Steve
>>>>>>>>
>>>>>>>>> I can't produce an artificial output because this would defeat the
>>>>>>>>> purpose of the plug-ins since an message box would appear.
>>>>>>>>> A good solution would be that an empty string ("") as last
>>>>>>>>> statement
>>>>>>>>> is a valid return possibility and it would neither trigger a
>>>>>>>>> message
>>>>>>>>> box nor a log entry.
>>>>>>>>> In this fashion, NIL could still raise an error and thus indicate a
>>>>>>>>> problem with the code.
>>>>>>>>> You can see it likewise as a kind of "Skip processing this track"
>>>>>>>>> For instance:
>>>>>>>>> (if (soundp *track*)
>>>>>>>>>     do something
>>>>>>>>> ;else
>>>>>>>>> "")
>>>>>>>>>
>>>>>>>>> In other words, process only mono tracks that are selected.
>>>>>>>>>
>>>>>>>>> Robert
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 12/06/2017, Steve the Fiddle <[hidden email]> wrote:
>>>>>>>>>> I am considering removing that as I agree it does not appear to be
>>>>>>>>>> very useful, but it does provide information about what Nyquist is
>>>>>>>>>> doing that is not otherwise available.
>>>>>>>>>>
>>>>>>>>>> If, for example, you view the debug output from the Nyquist Prompt
>>>>>>>>>> from the command:
>>>>>>>>>> (print "Hello World")
>>>>>>>>>> You will see there is no error reported.
>>>>>>>>>>
>>>>>>>>>> On the other hand, if you do the same with the command:
>>>>>>>>>> (print (list "Hello World"))
>>>>>>>>>> then you will see the error message:
>>>>>>>>>>
>>>>>>>>>> "Nyquist error returned from Nyquist Prompt:
>>>>>>>>>> ("Hello World")"
>>>>>>>>>>
>>>>>>>>>> The reason that you see the error message in the latter case, is
>>>>>>>>>> because a string list is not defined as a valid return type.
>>>>>>>>>> Anything
>>>>>>>>>> that is not defined as a valid return type is defined as an error
>>>>>>>>>> type. The change is that the debug window now tells you that
>>>>>>>>>> Nyquist
>>>>>>>>>> has returned an error type rather than not telling you.
>>>>>>>>>>
>>>>>>>>>> I think the question is whether it is useful for debugging
>>>>>>>>>> purposes
>>>>>>>>>> to
>>>>>>>>>> know whether the returned type is a string or an "error" type.
>>>>>>>>>> Previously we have hidden that information.
>>>>>>>>>>
>>>>>>>>>> Steve
>>>>>>>>>>
>>>>>>>>>> On 12 June 2017 at 10:37, Robert Hänggi <[hidden email]>
>>>>>>>>>> wrote:
>>>>>>>>>>> The recently added
>>>>>>>>>>> "Nyquist error returned from Nyquist Prompt:" is imho pretty
>>>>>>>>>>> useless
>>>>>>>>>>> and annoying.
>>>>>>>>>>> This belongs to the title bar if anywhere.
>>>>>>>>>>> There is absolute no error in the code when I simply want to
>>>>>>>>>>> debug
>>>>>>>>>>> a
>>>>>>>>>>> variable or property or some other information.
>>>>>>>>>>> Also, the "Nyquist returned NIL" is still reported in the log
>>>>>>>>>>> file
>>>>>>>>>>> and
>>>>>>>>>>> thus cluttering it unnecessarily.
>>>>>>>>>>>
>>>>>>>>>>> Robert
>>>>>>>>>>>
>>>>>>>>>>> ------------------------------------------------------------------------------
>>>>>>>>>>> Check out the vibrant tech community on one of the world's most
>>>>>>>>>>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>>>>>>>>>>> _______________________________________________
>>>>>>>>>>> Audacity-quality mailing list
>>>>>>>>>>> [hidden email]
>>>>>>>>>>> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>>>>>>>>>>
>>>>>>>>>> ------------------------------------------------------------------------------
>>>>>>>>>> Check out the vibrant tech community on one of the world's most
>>>>>>>>>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>>>>>>>>>> _______________________________________________
>>>>>>>>>> Audacity-quality mailing list
>>>>>>>>>> [hidden email]
>>>>>>>>>> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> ------------------------------------------------------------------------------
>>>>>>>>> Check out the vibrant tech community on one of the world's most
>>>>>>>>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>>>>>>>>> _______________________________________________
>>>>>>>>> Audacity-quality mailing list
>>>>>>>>> [hidden email]
>>>>>>>>> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>>>>>>>>
>>>>>>>> ------------------------------------------------------------------------------
>>>>>>>> Check out the vibrant tech community on one of the world's most
>>>>>>>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>>>>>>>> _______________________________________________
>>>>>>>> Audacity-quality mailing list
>>>>>>>> [hidden email]
>>>>>>>> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>>>>>>>>
>>>>>>>
>>>>>>> ------------------------------------------------------------------------------
>>>>>>> Check out the vibrant tech community on one of the world's most
>>>>>>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>>>>>>> _______________________________________________
>>>>>>> Audacity-quality mailing list
>>>>>>> [hidden email]
>>>>>>> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>>>>>
>>>>> ------------------------------------------------------------------------------
>>>>> Check out the vibrant tech community on one of the world's most
>>>>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>>>>> _______________________________________________
>>>>> Audacity-quality mailing list
>>>>> [hidden email]
>>>>> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>>>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>> Check out the vibrant tech community on one of the world's most
>>>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>>>> _______________________________________________
>>>> Audacity-quality mailing list
>>>> [hidden email]
>>>> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>>>
>>> ------------------------------------------------------------------------------
>>> Check out the vibrant tech community on one of the world's most
>>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>>> _______________________________________________
>>> Audacity-quality mailing list
>>> [hidden email]
>>> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>>>
>>
>> ------------------------------------------------------------------------------
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> _______________________________________________
>> Audacity-quality mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Audacity-quality mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Audacity-quality mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-quality