On Wed, Apr 11, 2012 at 10:31:24PM +0300, Kai Vehmanen wrote:
>
> The first sleep is due to the above, but the second one is a bit
> suspicious. There should not be any need to have a sleep before
> start. If this causes errors, then the cause is probably something
> else.
I don't think the second sleep was necessary. It's just that the
replace_effect logic was wrapped in a generic stop_do_start logic, which
I think Joel initially created to mitigate the seek problems.
Originally, the logic would stop, execute command, sleep, and start,
which worked for seeking but didn't slove the crash for bypassing.
Moving the sleep before execution did solve the problem, but I didn't
want to cause other problems, which is why I split the sleep period to
sleep before and after.
Cheers,
S.M.
-- ------------------------------------------------------------------------------ For Developers, A Lot Can Happen In A Second. Boundary is the first to Know...and Tell You. Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! http://p.sf.net/sfu/Boundary-d2dvs2 _______________________________________________ Ecasound-list mailing list Ecasound-list@email-addr-hidden https://lists.sourceforge.net/lists/listinfo/ecasound-listReceived on Fri Apr 13 00:15:02 2012
This archive was generated by hypermail 2.1.8 : Fri Apr 13 2012 - 00:15:02 EEST