I am also working with schedwhen and I was about to mail some questions to the 
list when they were answered. I did find some ways to work around the bugs in 
the code.

To have multiple activations of schedwhen, it needs to be reinited. 
For instance:

initsched:
     schedwhen ktrigger,.......
rireturn
if ktrigger !=0 goto continue
reinit initsched
continue:

The if-statement prevents schedwhen from reiniting and activating every 
performance-pass for as long as ktrigger!=0. Once the trigger is back to 0, the 
code is reinited and can be activated again. 
It would be nicer, I think, if there was a release parameter in the opcode, more 
like a drum-pad. But since there isn't, it makes sense to me to have to reinit 
it for multiple activations.

To prevent the called instrument from stopping when the calling instrument 
stops, the following helps, (I don't know why):
In the beginning of the instrument

itime times
p2=itime


On the other hand, to have it stop sooner, something like this works:

ktime timeinsts
if ktie>=p3 goto off
....
...

goto end

off:
turnoff
end:




I'm using these to write a kind of "a-live" sound-bugs that crawl around the 
sound-stage, reproducing when they meet. It makes more sense to program the 
algorithm in the instrument,in this case, than to use a score generating 
software.