Speech synthesis blocks interpreter

[ceremona]

OSX 10.8.5

Was playing around with some sc tweets:

t=("it's gonna rain "!999).join;Speech.init(2);[98,99].do{|r,i|Speech.setSpeechVoice(i,3).setSpeechRate(i,r).channels[i].speak(t)};// #sc sr

I cannot kill/stop/reboot my server when running this. Runs forever. cmd"." doesn't stop it.

Seems like a bug....

[ceremona]

Gui Server.reboot gives RESULTS = 0
Gui Server.Kill All Servers gives RESULTS = 1

[joshpar]

I’m pretty sure Speech is run with the OS speech synthesis, NOT sc or its server. It is piped out as a shell command.

---

/* Joshua D. Parmenter
http://www.realizedsound.net/josh/ http://www.realizedsound.net/josh/

“Every composer – at all times and in all cases – gives his own interpretation of how modern society is structured: whether actively or passively, consciously or unconsciously, he makes choices in this regard. He may be conservative or he may subject himself to continual renewal; or he may strive for a revolutionary, historical or social palingenesis." - Luigi Nono
*/

On Jun 27, 2015, at 5:59 PM, ceremona notifications@github.com wrote:

Gui Server.reboot gives RESULTS = 0
Gui Server.Kill All Servers gives RESULTS = 1

—
Reply to this email directly or view it on GitHub #1570 (comment).

[scztt]

@joshpar is right, it's just running a command. It's blocking too (the .speech call), meaning sclang doesn't come up for air until it's made it's finished with both commands entirely.

[ceremona]

Ya, realized that was a OSX native call after I posted. Still. It would seem like Quitting the server shouldn't be contingent on some shelled/piped process that's gone rouge.

[scztt]

Unfortunately, the server is owned by the language, and in the case of your tweet, the language is hung until all the speech finishes.

[jamshark70]

Hm, "enhancement" but what would the fix be? To make the speech call asynchronous (so that it doesn't block the language)?

It would seem like Quitting the server shouldn't be contingent on some shelled/piped process that's gone rogue.

There's no way really to prevent this. You can run an infinite loop in the language, and then the language will be unable to stop the server, just as in the case of a time-consuming system call that's running synchronously. If you run "killall scsynth" from the terminal (outside the control of the language), that should work.

Bottom line is, if the language is blocked, then it's blocked and you can't expect it to do nice things like stop servers.

[scztt]

Sorry, I should have been more specific... yes, the enhancement is to make the speech call (or, actually, all of the unixCmd related methods) non-blocking. This is actually a big problem for Quarks at the moment, as it will hang sclang in case of any git connection problem for example. I was going to close, as the non-blocking thing is already tracked in a bug elsewhere I believe, but I figured I'd let @ceremona respond / do the honors if there's no further discussion to be had.

[ceremona]

Nothing more to say. You can close or do whatever is appropriate. Thanks folks. Process does kill for the outside terminal process as expected.

[telephon]

make … all of the unixCmd related methods) non-blocking.

it would be good if this were optional, as it may break code in subtle ways.

[danstowell]

It would certainly change the timing of various command sequences that included unixCmds, and would definitely be likely to break code which expected completion ie blocking. No, there should be no such change.

Some confusion in the above discussion: firstly, unixCmd is already non-blocking. we have systemCmd for blocking. But more importantly, .speak is implemented as a primitive on OSX, not a shell command. Ignore the shell discussion, it's irrelevant.

[nhthn]

Closing because Speech has been removed entirely.