On 11/11/10 10:11 PM, Anthony Howe wrote:
Key problem? All of these implementations deliver repeatable, less than desirable responsiveness from the button that is being clicked by the user to trigger the audio. It's just initiating playback too slowly to cut it as a playable 'instrument'.
Fastest results will be with an embedded audio clip, so don't use a player, use the "play audioclip" command. Then see if performance improves if you suspend the development environment (last entry in the Development menu.) The IDE has a constant stream of behind-the-scenes messaging going on, with lots of pending messages and interceptions. These may be slowing down the response. Suspending the IDE removes these.
Also, the first access to the sound clip can be slower because it needs to load. Repeated access after that should be pretty quick. But different things can unload it again. I'm not sure exactly what does that, but I've noticed it when changing cards.
If that doesn't work, see if using a keyboard key is faster. Try a keydown handler.
-- Jacqueline Landman Gay | jac...@hyperactivesw.com HyperActive Software | http://www.hyperactivesw.com _______________________________________________ use-revolution mailing list use-revolution@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
