Subject: Re: signals

From: "Rosen, Brian" <[email-masked]>
Date: Tue, 23 Nov 1999 08:28:27 -0500

> 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.
While we did spend a lot of time, in retrospect, we wasted a
lot of time without a good understanding of how these problems
have been solved with MGCP.  We don't have to slavishly follow
MGCP, but IMO we should understand what they did, and why, and
any new idea we come up with had better be really useful,
and not miss anything that MGCP has.

> 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 disagree.  I think it is a significant amount of implementation code.

> I do not also see how OO needs more messages than brief. Use OO with
> NEXT its the same thing.
OO always needs at least two messages ON and OFF.  It never
has any timing problems, and it never has any completion event.

TO is a signal with problems (and ONCE if there is a difference between it
TO with Duration=one cycle).  It has a problem because you don't know, when
you send a new SD, what the state of prior TOs are.  Completion events,
which we all agree are needed,
solve that problem.  If BR queues, then it doesn't have a problem.

I don't think SD(x) is not yet "cooked".  I'm still confused,
for example, on whether you can ever "recycle" an "x".

At this point, I am very reluctant to stray from well traveled paths.  A
month ago, I may have been more open to this idea.
For me, this is too much of a change now.

Brian

> Cheers, Christian
>
> "Rosen, Brian" wrote:
> >
> > 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 14:41:34 +0100

G'Day Brian,

See CHG.

Cheers, Christian

> I disagree.  I think it is a significant amount of implementation code.

[CHG] OK so we agree to disagree :)

> has any timing problems, and it never has any completion event.

[CHG] Sorry meant to say ONCE instead of OO.

> for example, on whether you can ever "recycle" an "x".

[CHG] Yes

> For me, this is too much of a change now.

[CHG] This idea has been around since the Redbank meeting (approx 1
month ago). People had similar attitude to it back then but we've
returned to it. Its time to explore it further. Nobody has presented any
problems with it yet.