Possible Goofy Fix Found for Missing PlayStopped
After spending the better part of today messing around with players, sound files and wet towels to clear the bloody remains from my forehead, I may uncovered a goofy fix for the missing playStopped message Jacqueline and I batted around in December. The RunRev folks may have already implemented a fix for this, but in case they haven't, here's a recap: On 12/5/03 11:14 AM, J. Landman Gay [EMAIL PROTECTED] wrote: Make a stack with a single player object, and assign the player an audio filename. I haven't tried with MP3 files, because my sources are all audio-only quicktime movies. So maybe try one of those. Then put this script into the card: on playLoop global gPlay if the shiftkey is down then -- stop loop put false into gPlay else put true into gPlay start player 1 end if end playLoop on playStopped global gPlay if gPlay = true then playLoop end playStopped Trigger it with either a button or from the message box, with playloop. While it plays, click back and forth between the stack and the message box. You should see the problem. If the stack is frontmost, you don't get a playStopped message. You can verify by watching the message watcher, though the behavior speaks for itself. OK, so while playing around with this stuff, I tried to find some way to force update the player or the card, and discovered by accident that resizing the stack causes the loop to continue. So I created a repeating handler that continuously sets the rect of the stack to itself (hey, I said it was goofy, I didn't say it was pretty). The above script was modified as follows: on playLoop global gPlay if the shiftkey is down then -- stop loop put false into gPlay stop player 1 else put true into gPlay start player 1 goofyFix end if end playLoop on playStopped global gPlay if gPlay then playLoop end playStopped on goofyFix global gPlay if not gPlay then exit goofyFix set rect of this stack to rect of this stack send goofyFix to me in 100 milliseconds end goofyFix The strange thing is, even though the script seems to work, the playStopped handler won't return the name of the stopping player, which almost leads me to believe whatever mechanism is handling the player messages is leaving out that information somewhere. Anyway, hope this is useful for folks in the interim. [Tested on OSX 10.2.8] Regards, Scott Rossi Creative Director Tactile Media, Development Design - E: [EMAIL PROTECTED] W: http://www.tactilemedia.com ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
Re: Possible Goofy Fix Found for Missing Playstopped
On 1/31/04 1:27 PM, Alejandro Tejada [EMAIL PROTECTED] wrote: After spending the better part of today messing around with players, sound files and wet towels to clear the bloody remains from my forehead, I may uncovered a goofy fix for the missing playStopped message Jacqueline and I batted around in December. The RunRev folks may have already implemented a fix for this [snip] Hi Scott, I've tested this handler in windos 98 and it works as expected, but after a while running, (maybe 5 minutes) i get a msg of the system telling me that 90 % of the resources are in use. This loop handler is very useful, so how could we stop it of eating system resources? Could someone else test this in their system? As far as I heard, the missing playStopped problem does not occur on Windows. Perhaps you should verify this first before attempting to apply the goofy handler. Regards, Scott Rossi Creative Director Tactile Media, Development Design - E: [EMAIL PROTECTED] W: http://www.tactilemedia.com ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
Re: Possible Goofy Fix Found for Missing PlayStopped
On Jan 31, 2004, at 12:00 PM, [EMAIL PROTECTED] wrote: [Possible Goofy Fix Found for Missing PlayStopped] I am using whatever underlying engine is included with Rev 2.03, and I don't seem to be having problems with PlayStopped messages. I have a stack that relies upon that message extensively (it plays movies in succession), but then again you didn't say that you were trying to play video files. This is important to me, since I could not use a newer version of Rev until this problem (and the other one that prevents controller updates on audio QT players in OS X standalones) were to be fixed. -Kurt ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
Re: Possible Goofy Fix Found for Missing PlayStopped
On 1/31/04 5:31 PM, Kurt Kaufman wrote: I am using whatever underlying engine is included with Rev 2.03, and I don't seem to be having problems with PlayStopped messages. As far as I know, it was a bug introduced recently (possibly version 2.1.2 but I'm not sure) and it only happens on OS X. -- Jacqueline Landman Gay | [EMAIL PROTECTED] HyperActive Software | http://www.hyperactivesw.com ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
Re: Possible Goofy Fix Found for Missing PlayStopped
On 1/31/04 1:07 AM, Scott Rossi wrote: on playLoop global gPlay if the shiftkey is down then -- stop loop put false into gPlay stop player 1 else put true into gPlay start player 1 goofyFix end if end playLoop on playStopped global gPlay if gPlay then playLoop end playStopped on goofyFix global gPlay if not gPlay then exit goofyFix set rect of this stack to rect of this stack send goofyFix to me in 100 milliseconds end goofyFix The strange thing is, even though the script seems to work, the playStopped handler won't return the name of the stopping player, which almost leads me to believe whatever mechanism is handling the player messages is leaving out that information somewhere. Anyway, hope this is useful for folks in the interim. Wow. The goofiness of the fix almost makes it worth having the bug in the first place. :) -- Jacqueline Landman Gay | [EMAIL PROTECTED] HyperActive Software | http://www.hyperactivesw.com ___ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
