Re: [misterhouse-users] CID on Version 2.75 posted on 12/23/2002

[Steve S. <st...@sw...>]

Jason,
   The respond function was meant for text. I'm sure you can send a wav file
name, and parse that in the respond_callid function, but I think that adds
to much logic the the user-configurable function.
Maybe respond isn't a good idea here. Let's consider adding two functions...
one that allows the user to tap in and control things, which by default only
calls another function, where all the wav file logic and parsing is.

sub callid_pre_speak() {
   &callid_speak(@_);
}
sub callid_speak() {
   #Place are parsing and logic for .wav decisions here... be sure to accept
parms for rooms=, volume=, etc.
}

We can then place a function inside of user code that'll allow anyone to
customize their announcements.

sub callid_pre_speak() {
   &callid_speak(@_) if !$Dark;
}

The above is an over-simplified version, but you get the idea... :)

-Steve

----- Original Message -----
From: "Jason Sharpee" <ja...@sh...>
To: <mis...@li...>
Sent: Wednesday, December 25, 2002 10:04 AM
Subject: Re: [misterhouse-users] CID on Version 2.75 posted on 12/23/2002


>
> On Tue, 24 Dec 2002, Steve Switzer wrote:
>
>
> I would also need to be able to play a .wav file if specified instead as
> well.   Should I pass the .wav filename into the respond function if
> specified instead, and let the callback function /.wav$/ to make the
decision on how to
> respond?  I guess it would be nice to have both the text and wav file name
> available in the user callback, in case the interface does not have audio.
> Should I be passing both then?
>
> -J