
R1D1

I have been using the "SAY" command in a few of my subroutines. Since I updated my ARC version this week however, I've noticed that the SAY command no longer works on my Mobile, unless I've done something else wrong, as I'm continually trying to add more functionality to my robot.
When my code comes to the SAY command when I'm running my robot from my PC however, it works. It only doesn't work when I'm connected to my tablet, and the same programs worked last week. And yes, the volume is turned on my tablet, and it will make other sounds not emanating from EZB.
Has anybody else experienced this as of this week, or am I overlooking some other setting in EZB that I accidentally changed?
Check the Application Log and see if there are any errors that you can share.
Code:
I think it causes the system to skip the usual operation since, when inserted into the string, the red color indicating how long the command is running (in a SayWait command) just flashes for a moment. Whereas, normally it takes a couple of seconds or so to say the message I gave as an example above. Perhaps there are other such sequences that inhibit sound as well?
Error on line 4: Cannot change synthesizer's output while speaking.
This is line $ that it is referring to:
Code:
Does this help?
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:
Notice how there are spaces between the words and quotes.
I have added other subroutines unrelated to this on since that time. Could there be a conflict somewhere that I should be looking for?
Alan
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 &. 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?