Such "extra time before actual abort" is consistent with the performance of 
"time" for the e statement:
"The first p-field time determines the extra time (in seconds) to be given 
to the performance after the actual e statement takes effect."

So, IMO, the "time" parameter does make sense with the event opcode (though 
not in the context I am working with).

Art Hunkins

----- Original Message ----- 
From: "Anthony Kozar" 
To: 
Sent: Wednesday, February 06, 2008 12:16 AM
Subject: [Csnd] Re: Re: Re: Re: "Abort" Command?


> Note that the info in the manual about the optional "time" parameter to 
> "e"
> is wrong.  It does not _add_ the specified amount of time to the end of 
> the
> score, it _is_ the time of the end of the score (in beats, assuming that
> "time" is later than the end of the last event).
>
> I corrected this for the next edition of the manual.
>
> Therefore, I am not sure how it makes sense to interpret this parameter 
> with
> the "event" opcode.
>
> Anthony
>
> Art Hunkins wrote on 2/5/08 11:19 PM:
>
>> Developers:
>> I'd like to request that someone fix event for the "e" case. The 
>> parameters
>> are different for (score event) e. The single and *optional* parameter
>> should be time (as with e). Unfortunately, this parameter (for event "e")
>> does not work to delay the "abort", so that currently "abort" is always
>> immediate.
>
>
>
> Send bugs reports to this list.
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe 
> csound" 

Art Hunkins wrote on 2/6/08 6:17 AM:

> Such "extra time before actual abort" is consistent with the performance of
> "time" for the e statement:
> "The first p-field time determines the extra time (in seconds) to be given
> to the performance after the actual e statement takes effect."

My point was that the above quotation from the manual is wrong -- that is
not how the optional "time" parameter works.

> So, IMO, the "time" parameter does make sense with the event opcode (though
> not in the context I am working with).

I am not so sure that it does.  Let me explain how the "time" parameter is
implemented.  When you end your score file with

e 20.0

Csound expands this to

f0 20.0
e

in the sorted score.  So, this is just a "convenience" feature in the
unsorted score syntax.  I requested that the feature be added because using
the "f0" statement to extend a section is unobvious and not as logical as
simply specifying the end time of the section in the "s" or "e" statement.
(It works for "s" statements too).

The second important thing to understand here is that Csound has _two_ score
parsers.  The first one ("sread") reads the unsorted score, expands macros,
evaluates expressions, carries pfields, sorts the events, tempo warps
everything, fills in ramps, and finally writes out the sorted score to
"score.srt" or a temporary file.

The second score parser ("rdscor") reads the sorted score back in for
performance.  It expects to find only i, f, s, e, t, and "w" statements in
the score -- because those are the only events that the orchestra actually
understands -- and it knows nothing about macros, expressions, carry, etc.
And as far as rdscor is concerned, the "e" and "s" statements have no
parameters.

The "event" opcode only supports select score statements for much the same
reason that rdscor does.  And so this is sort of why it does not support the
"time" parameter for "e".  This is not to say that it could not be
implemented somehow, but there is a "precedent" for the behavior.

I guess the important question is whether anything is really gained by
changing how "e" works with "event" or should we just document the
difference?

Anthony

>> Art Hunkins wrote on 2/5/08 11:19 PM:
>> 
>>> Developers:
>>> I'd like to request that someone fix event for the "e" case. The
>>> parameters
>>> are different for (score event) e. The single and *optional* parameter
>>> should be time (as with e). Unfortunately, this parameter (for event "e")
>>> does not work to delay the "abort", so that currently "abort" is always
>>> immediate.