Hi,
> > Yes, but the finish signal should be sent when DoSound(STOP_ALL) is issued.
> > /If/ it is issued...
>
> It's never getting issued, basically. :/ While I agree there could be
> some screwyness in the communication pipes, the DoSound() call would
> still register...
But it's only issued if the loop cue registers (see my code for
reference).
> > If you answered 'yes' to my last question, then I agree. In case you need
> > any helpful suggestions, try to check whether both events were received
> > during the same call of process_sound_events(), and try to assert that their
> > write operations wrote the numbers we wanted them to write.
>
> Sometimes they are, but other times they aren't. The "loop" signal is
> the latter one of the two when they are both received, in any case.
Is it written to the object correctly?
> I'm more intrigued by the 'invalid suspend handle' problem though -- In
> arthur, it happens each time you change the direction you're walking
> in... a lot of calls to Kfunc 0x71 (joystick). Could there be some
> kind of side effects to that unimplemented function?
Don't see why. They're not related in any way, and AFAIK Joystick is only
supposed to report motion events.
> (that's in
> addition to the pair of suspends in the text emtry box..)
>
> After more poking around lsl3, it seems as if that the current sound
> handle should be explicitly kept around somewhere, but isn't.
I don't know if you're doing this already, but if you have the hardware
and software to do so, you should try to check these things with Sierra's
interpreter occasionally (the handle is probably stored in a global
variable, so it should be easy to access there).
> (I don't suppose there's a way to set a breakpoint on "any access to
> object foo" is there?)
Now there is.
llap,
Christoph
