Re: Speak errors (was Re: audio)
- To: mathgroup at smc.vnet.net
- Subject: [mg130627] Re: Speak errors (was Re: audio)
- From: Clif McInnis <c_mcinnis at hotmail.com>
- Date: Fri, 26 Apr 2013 23:09:58 -0400 (EDT)
- Delivered-to: l-mathgroup@mail-archive0.wolfram.com
- Delivered-to: l-mathgroup@wolfram.com
- Delivered-to: mathgroup-outx@smc.vnet.net
- Delivered-to: mathgroup-newsendx@smc.vnet.net
- References: <17744967.14121.1366277874273.JavaMail.root@m06>
Hi debguy, Yes, I think that a race condition is what is happening. When the code is run without Pause statements, the graphics can easily race ahead of the audio, and when Pause statements are included, after each speak[], the audio races ahead of the graphics. I tried to find "FrontEndEvaluate" in the Documentation Center, but it gave me "FrontEndExecute" (which did not seem to address the question) instead. I have also tried to disable the buttons (Enable-> False) when the button is pressed and have them enable again when the graphics has updated, but that doesn't seem to work(does about the same thing as the pause statements). I appreciate all suggestions. > (a race condition - that is why I suggested simple waiting. i see no > > solution posted above so let me try again....) > TRY THIS: > The Front-End has it's own evaluator separate from the kernel. I'm > > thinking maybe that's where your split (and then race condition) > > occurs. Make sure all expressions effected are done by one or the > > other but are not split in-between both. See "FrontEndEvaluate" for > > more info. I'm thinking that because I beleive many new features todo > > with dynamic front end content have some level of integration with the > > new front-end evaluator.