Subject: Washington Issue 5 - Signals

From: Brian Rosen <[email-masked]>
Date: Mon, 15 Nov 1999 10:54:00 -0500

A number of issues were raised in the Washington meeting that were "send to
the
list".  This is one of these issues, with the problem and my suggested fix.

Problem:
Signals are confused, especially the behavior of "Brief".  Is there queuing?
The "list of signals" is also missing a few details.

Proposed Solution:
Please note that this solution differs from what was presented at the
meeting!

Signals have a "cycle" or "cadence", or a simple duration.  Signals have a
length, which is fixed or provisioned.  The length may include silence
periods,
components with changes in frequency, etc, or it may be instantaneous.
Brief is one cycle
TimeOut is repeat the cycle until:
        - the signals is explicitly turned off
        - an event (not marked Keep Active)
        - a timer expires
On/Off is repeat the cycle until it is turned off, or an event occurs

There is an event: SignalCompletion
It can be included in the EventDescriptor.  It has a parameter, which is
the list of signals.  If any of the signals mentioned time out, the event
is generated (note that any other event which would stop the signal will
generate a Notify).  This could be used with BR or TO signals.

List Of Signals
One cycle is the sum of the cycles of the list
Only the last item can be on/off
List of Signals has a signalType and Duration just as any signal would.

Loading a new Signals Descriptor changes signals:
        Signal in old list, not in new list stops
                Special Rule for Brief signals - execution of command waits
until
                        BR signal finishes.
        Signal in new list, not in old list starts
        Signal in both continues
The special rule can cause problems if the signal is not really Brief;
for example, if you start a 10 second BR signal, and then want to
interrupt it 1 second later, only an event would stop it.

Brian

---

From: Christian Groves <[email-masked]>
Date: Wed, 17 Nov 1999 15:51:33 +0100

G'Day Brian,

I definately think that Brief signals should be able to be stopped by
sending another signal. Having only an event is not sufficient. Ie.
announcements: you should be able to interrupt one. There should be no
special rule for brief signals.

Another problem is the rules for continue, replace and stop.
What happens if you have a brief signal (S1) and want to add another
signal (S2) to the signal descriptor(SD). S1 has just finished when you
send an ADD or MODIFY with SD=S1,S2 (you haven't received the
SignalComplete event yet) because you want S1 to continue playing. What
will happen is that you order S1 again and S2. You've played S1 twice
which is an error.

I would suggest coming back to a higher level for the replacement rules.
ie. the signal descriptor. I think having multiple descriptor each with
an ID would solve this.

ie.
Each group of related signals would be under a single signal descriptor
ID.
SD(x)=S1,s2,s3     would play s1 then s2 then s3

Each group of unrelated signals would be under different signals
descriptor ID.
SD(y)=s4
SD(z)=s5  would play s4 and s5 at the same timout.

To stop signal/s the appropriate SD(ID) would be given.

Type of signal rule is the same as your list proposal. ie. ON in the
middle of SD doesn't make sense. No special rules are needed depending
on type of signal. The repeating of signals isn't a problem.

Cheers, Christian