Testing...

The Say() command works on both my iOS and Android device. Has there been an update to your mobile device that might have changed the language or region?

Check the Application Log and see if there are any errors that you can share.

Speaking of the Say command. By accident I recently found that if this character sequence "<p>" is anywhere in a string to be spoken, the command doesn't work. At least, if it is working, there is no sound coming from either the PC speakers or the robot. Like this:

Code:

SayWait("Testing this  message") #Normal
SayWait("Testing this <p>  message") #Silence
SayWait("<p>Testing this  message") #Silence
SayWait("Testing this  message <p>") #Silence

I didn't think to look in the application log. I just looked at it and saw this error;

Error on line 4: Cannot change synthesizer's output while speaking.

This is line $ that it is referring to:

Code:

sayEZB("Distance" + $Distance + "inches")

Does this help?

I should also probably add that the sayEZB command does work on my tablet, it's only the SAY command that does not work.

First, please post code using the [ code ] and [ /code] tags for proper formatting. I've edited your posts.

Second, perhaps the speech synthesizer on the device that you're using is not able to parse the phrase to be spoken. There are no spaces in the phrase which you have pasted, so the number and words all blend together. Because android is not a regulated operating system, every device and manufacturer is different - making it very very difficult for ezrobot to support every android flavor. I would recommend fixing the syntax is the say command to include a space between the number variable and words.

Code:

SayEZB("distance " + $distance + " inches"

Notice how there are spaces between the words and quotes.

I tried the spaces in the text to be spoken as you suggested, but unfortunately this did not help. I might also add, that last week I had the text without the spaces and it was working them.

I have added other subroutines unrelated to this on since that time. Could there be a conflict somewhere that I should be looking for?

@WBS00001 Am I missing something? Why does it matter? How is "<p>" used in text to speech synthesis anyway?

Richard R, I think that might have come our of WBS's HTML parsing project. "<p>" is an HTML paragraph break, so if you are trying to convert HTML to a TTS string, and it breaks TTS, it needs to be stripped out.

Alan

@thetechguru Correct. I mentioned it because there might be other characters or character sequences that could cause problems as yet unknown. Including characters that would not be visible normally (control characters).

And no, the HTML project is concerned only with stripping out characters and character sequences that cause the scripts to crash due to bugs in the script language (Backslash+quote, Left paren.,capital E followed by a number). And, of course quote marks themselves, but that's not really a bug. Then there is the amp part of &amp. Things like that. The rest get removed by the SubString function when extracting the desired data from the scrubbed text. The <p> got in by mistake and caused some lost time trying to figure why there was suddenly no speech being heard. I saw it in there but didn't think anything of it. It took a while to finally determine that it was the cause of the problem.

Plus I found it very strange that the <p> sequence actually had an effect on the speaking in the first place. Especially the fact that it didn't matter where in the string the <p> was. Makes me wonder if, whatever the algorithm is, it responds to other things. I tried some other common HTML sequences but nothing. In fact it didn't even speak them. It just seemed to ignore them. That makes me think it knows about HTML control character sequences and is set to self filter them unless it is something it recognizes. If so, what else does it recognize?

Now all I need to do is think of a way to exploit this oddity. Streaming on-off control?

Thanks