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”

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.

Both as a Skill Developer and as a potential User, my first impulse is to make the presence or absence of a semaphorical sound (semaphone? phonosemaphore?) a user configurable option. I.e., device configuration page would offer switches or radio controls to enable or disable (or perhaps conditionally enable) that behavior, per device. So I think the most consistent option would actually be a mix of first and third option: kind of an optional semantic tag (which later on could have a few other values other than error), but attached to the already established speak_dialog method (i.e., speak_dialog(dialog, data, type=“error”) ).

Purely as a sci-fi fan user: I think it would be really cool to have not only that option to enable event audio signals (acknowledge, error, long-running-task-complete, and of course already existing “listening” sound and time-out-expired sound), but also to have “audio themes”. Maybe one or two classic-but-copyright-free themes are included, but tech-tinkerer users could upload some replacement Star Trek Enterprise LCARS sound effects or your own DIY effects.

Final thought: in some future time if Mycroft were to have expanded accessibility features, the idea of semaphore could be abstracted a little and have additional options for visual surrogates to the audio sounds. For example: a deaf user might enable (on a Mark II or better) a visual signal where the whole screen or maybe just a thick border flashes twice red, perhaps along with the led ring. That could setting could just be side by side with the audible signal settings on

1 Like

I’m scared people will think this isn’t helpful at all, so uh…I can delete this if it doesn’t contribute to the discussion, because in terms of programmer ability, I’m what you call a “non-programmer”. (Though, I’m trying to learn some Python so I can write some skills…wish me luck.)

I agree with both posters here that flexibility is the way to go. (And I’m fully down with @jrwarwick’s idea to use LCARS sound effects, because I basically want to live on The Enterprise. (E)) Specifically with regard to errors, especially ones that use the fallback response (which I personally do not care for, I’d rather hear a short sound than the fallback) the sort of option I’d find most useful as a user would be a simple error sound. In the case of the fallback skill, that’s all that would be necessary. Then further information could be requested from the system, with something like “What’s the problem?”, “Why not?” or “Clarify” or “Explain”.

Standards for skills to try and turn errors into user-friendly explanations could potentially fit into that sort of framework going forward. For example, I imagine the following conversation.

“Hey Mycroft, play “Shake It Off” by Taylor Swift.”
(sad beep)
“Hey Mycroft, Clarify?”
“Unable to connect to Spotify. Other internet connections are unaffected.”

1 Like

Love the ideas, the concept of theming would be a very cool personalisation feature - in the perfect world this would include LCARS GUI screens, TTS voice, sound package, and modified dialog for at least the system default stuff.

Also great to be thinking about users with different interfacing needs!

1 Like

I love it, Gez! Full theme packages. It seems obvious now that you have described it. I’m seeing Pip Boy from Fallout, a few 'Trek themes (of course), StarCraft Adjutant, Cortana (Halo), MCP (Tron), Jarvis ( Marvel movies), HAL9000, GLaDOS (half-life), etc. Each with a couple of coordinated just-for-fun inside-joke skills (a la “beam me up”) appropriate to the fictional universe the theme represents.