Subject: Re: signals

From: "Rosen, Brian" <[email-masked]>
Date: Mon, 22 Nov 1999 18:01:24 -0500

I think it is very, very late to make the kinds of changes
that are proposed, regardless of whether they represent some
great ideas or not.

The proposal on the table (BR, TO and OO), with a special
queuing for BRief is the smallest delta from where we were
to something that works.  It also has the advantage of being
very close to MGCP, which we have experience with, and it
seems to work.

I think the amount of code and mechanism need to implement this
proposal is far in excess of the corresponding increase in
practical capability you get from it.  I'll grant you that it
has a good deal more expressive power, but I think it's wasted
power - the problems it solves are not actual problems.

Completion events and simultaneous signals gets you both sequential and
simultaneous capability without any significant
corner cases.  BR simply uses one less message when it is appropriate, and
useful to do so.

Brian

> -----Original Message-----
> From: John A. Voelker [mailto:[email-masked]]
> Sent: Monday, November 22, 1999 5:17 PM
> To: [email-masked]
> Subject: signals
>
>
> 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
>

---

From: Christian Groves <[email-masked]>
Date: Tue, 23 Nov 1999 13:15:54 +0100

G'Day all,

I thought the whole idea of discussing signals and events was that we
needed to make changes to get them to work properly. We spent alot of
time at RedBank until now discussing Signals and people have said that
BR,TO and OO do not cover all their needs. Each patch we've managed to
find an issue with.

I don't agree with the statement that the SD(x) and NEXT needs a great
deal more code. The MG already has the code to do sequencing and
simultaneous playing. The proposal of SD(x) and NEXT or FLUSH might make
code and mechanism easier because it will be explicit what you have to
do.

I do not also see how OO needs more messages than brief. Use OO with
NEXT its the same thing.

Cheers, Christian