Mycroft Community Forum

Short sound to indicate error

As a Skill developer if there is some error currently you generally speak some dialog, eg:

“something went wrong”
“I didn’t understand which movie you meant”
“I can’t connect to X please check your settings”
etc

Sometimes though, you don’t need a long response, you just want a way to inform the user that it didn’t succeed. Well, there’s an interesting PR to add an error sound. Currently it’s only about an error sound, however this could very easily extend to other common sounds eg success, email sent, turned on, etc.

So I was wondering how Skill authors would prefer to use this. The existing suggestions are:

  • speak_dialog(dialog, data, is_error)
  • report_error(dialog, data)
  • report_outcome(type="error", dialog, data)

0 voters

If you have deeper thoughts, please comment here or join the discussion on this PR.

More flexibility is always good in such case, to cover warnings or other types of meta information in a generic way. This probably requires some sort of additional logging backend, so that log messages are optionally not only printed to file but additionally spoken, with a sort of identifying sound or prefix for each log level type.

Related additional config options could be:

  • acoustic_log_level=NONE (default) CRITICAL ERROR WARNING …
  • acoustic_log_dialog=true|false
    When false, play notification sound only which identifies the log level, but do not speak log text.

For logs below warning this probably doesn’t make sense as Mycroft-wide logs appear faster then it is able to speak them. But having a generic backend on regular/existing logging basis is probably better after all then adding a new independent type/set of functions?

Ah, I think when it’s disabled by default, it somehow breaks the idea to allow forcing the acoustic output by app developers? :thinking:
Although something informative like “I didn’t understand which movie you meant” is probably even better to have as gracefully “handled” regular answer, while errors are best to reserve for unforeseen issues, especially internal code errors, due to kernel/hardware-level, access issues and what not, that is not only due to an invalid question or non-accessible remote resource.

Another issue: Those python error traces can be very long and impossible to reasonably “speak”, so that would need to be excluded anyway… okay not as simple on the second thought.