Subject: signals

From: "John A. Voelker" <[email-masked]>
Date: Mon, 22 Nov 1999 16:16:50 -0600

I don't see a need for BR type signal.
I think the natural partitioning of kind of signal for control purposes is into
two types:
(a) signal that has a finite duration without external intervention,
(b) the complementary case (aka OO).
The finite duration of a type a signal takes into account multiple repetions of
some kind of signal elements.  E.g. "hello hello" is twice as long (+ plus gap
between word) as 'hello".  It is a second order issue whether the package
defines both "hello" and "hello, pause 1 second, hello" as distinct signals or
the package only defines "hello" and the SD syntax specifies two repetions.
Similary, it is a second order issue whether the package says apply this tone
for 200 msec or the package only specifies the tone and the SD specifies the
duration.

What I see is as more important is the following, largely following suggestions
from Christian.

Use something equivalent to SD id and an analog to Christian's NEXT.  For
variety and my own sense of aethetics I'll  propose a superficial modification
:  default behavior lets prior SD(x) signals continue to completion, FLUSH gets
rid of them.  The reason I slightly prefer this is that then the default
behavior (i.e. without FLUSH) between sequential SD(x) invocations mimics the
behavior between signals within a particular SD(x) invocation - namely, to
politely queue.

SD(x) = ([FLUSH],  list of signals) where only the last signal on the list of
signals can have indefinite duration (aka type OO).  The signals in the list are
applied in series, one commencing only after the prior signal completed its
normal life span.  If FLUSH is used, it stops whatever signal, if any, is both
currently actively applied (i.e. making noise on the termination) and was
specified part of a prior SD(x) command. Also the FLUSH removes any signals
queued from a prior SD(x) command.  Then the signals in SD(x) (FLUSH, signal
list) are sequentially applied.  If FLUSH is not present, the list of signals is
added to the end of any queue from prior SD(x) commands.

SD(x) and SD(y) operate completely in parallel sending signals, neither
interfering or canceling the other.  SD(x) and SD(y) may impose concurrent
signals on the termination.  Basically, SD(x) and SD(y) use different and
independent signal queues within the MG.  A FLUSH of one does not affect the
other.  Of course, the MGC needs to take care how it partitions signals between
SD(x) and SD(y).

Completion event is a good idea as the list seems to agree.  I would like to see
them reference the SD id and event position within the SD.  Consider double
indexing SD so that a completion event can refer to the second signal with the
87th SD(x).

continue:   default behavior
stop:  when explicitly ordered via a FLUSH parameter
replace: a FLUSH followed by a new reference to the signal

John Voelker