Simultaneous Audio Alert

[fish7]

I have two separate EFS routines written that give me an Audible alert (they play a wave file) when I get either of two different candle patterns on the price chart. They both work fine, independently.

Some times, the price candles print in such a way that both EFS routines should be called (and and both audio files should be played (sequentially, I hope)). But what happens, instead, is that only the first routine loaded into eSignal is played. If I delete that one, and re-load it, then the other routine is played. But I can't seem to get both to play, even though both should.

Both are set to compute on bar close.

Is there a way around this, besides combining all my EFS routines into one big EFS routine?

JOHN

f1sh7,

On one of the efs's, put in a delay to play the audible alert offset from the other one. That way you will hear them both, one after the other. Here is a function that I have used in the past.

function delay(gap){ /* gap is in millisecs */
var then,now; then=new Date().getTime();
now=then;
while((now-then)<gap){now=new Date().getTime();}
} 

This function needs to be placed outside main. To actuate the delay, call the function in this manner:

delay(1000);

I believe that will be a 1 second delay, but it has been a while since I used it. So I would start out small (e.g. 10) and work up.

[fish7]

Steve,

Thanks for the idea. That works, but has several problems:
(1) I need to know how long the prior (overlapping) audible alert is (they may not all be the same length -- I have several files w/audible alerts that could overalp, and don't always know ahead of time which one will be activated before any particular other one)
(2) the delay happens every time (even if it's not needed), making the notice unnecessarily late when there are no overlapping EFS audible calls
(3) if there are multiple simultaneous alerts that overlap, then the time delay on different ones needs to be adjusted even longer (to be the sum time needed for all prior audible delays).

What's needed is for the audibles that all fire at , say, bar close, should just "stack up" in a queue, and be played sequentially. If this can't be done, now, then, perhaps it's something that should be built into eSignal. It seems silly (as it's currently built) that whichever EFS is loaded first has such dominance that it squashes the next EFS's audible alerts completely (so that they're not even heard), rather than just having the audible alerts all just sequentially queue and be played one-after-the-other.

Thanks anyway. If there's a more elegant solution to this overlapping audibles problem that others know of, any suggestions would be appreciated.

JOHN

Hi John,

AFAIK, the sound queue you are referring is not available to efs. Here is a link to a slightly different method of providing a delay, however based on your discussion that probably does not meet you needs either.

To make requests for enhancements or new features send your suggestions to [email protected]

[fish7]

Steve,

First, what does AFAIK stand for?

Second, I found a slightly better way to get around the problem I have, using your delay routine. I know the length of each alert audio file in seconds (from playing them on the SoundRecorder utility in Windows), so I can accumulate the delay for each alert. I put together just two candle patterns here (Bullish Engulfing and Morning Star) in this little program. To run it, you'll need to change lines 12 and 13 to point to your wave files for the two patterns, respectively. And, you can put in the length of time (in milliseconds) that each is, in line 28 and 40, respectively, to customize it to how long your alerts are.

Thanks for your help. I will put in a suggestion to eSignal for a queue feature for audibles in eSignal.

JOHN

[fish7]

The EFS did not attach. Here it is now.

Hi John,

You are most welcome. Good to hear you found a workaround. BTW, when preparing a response and you use the preview post option, it clears the attachment block and you will have to put the attachment file back in. AFAIK is an acronym for "As Far As I Know". Here is a link of other acronyms used in online chat, e-mail, and newsgroup
postings.

[fish7]

Steve,

One thing I noticed.

I tried both of your delay routines. The first one (with newDate and getTime functions) really chews up a lot of CPU useage during tick-replay. The second one (that just counts up to a million or so) is better, but still chews up a lotta CPU when it triggers.

A more elegant way (though I am not sure how to code it), would be to append subsequent wav files together as the alerts are activated, and then play them as one file. For example if I have wave1file, wave2file, and wave3file, for each of 3 different alerts, and, say, for example, alert1 and alert3 tigger at the same time, then, first, append wave3file to the back of wave1file into a separate output file (call it CombinedWaveOutput) and then play that CombinedWaveOutput file. That would completely get around this whole need for delays, simplify the coding, and lessen the CPU useage.

Any idea how to append two separate wave files together w/in an EFS?

JOHN

Hi John,

Yes, both methods are CPU intensive due to them having to keep the processor busy to affect the delays.

Regarding appending the WAV files, I am not sure at this time if it could easily be done, nor if it would to be effective. This would be similar (albeit less work) to preparing a file for every possible combination, then calling the specific file, wouldn't it?

[fish7]

yes, that would have the same net effect. However, that makes the code rather rigid, and having a separate wavefile for every possible combination is tedious, to say the least, and makes subsequent addions/changes to the code tedious as well. It would be a lot easier to "accumulate" successive wave files together as the code figures out which patterns are triggered, and then just rattle them off sequentially. Of course, we wouldn't have to do any of this if eSignal would queue their alerts, rather than clobbering them when they occur simultaneously.

Thanks for your help, anyway. I'll see what I can do as a work-around/fix.

JOHN

[fish7]

Steve,

I just found out one other problem with using a counter-type delay as such. The charts I use during the day have a large backload of price data to get long moving averages. When I input my code that uses these audible alerts, eSignal saturates the CPU (upon startup) for a very long time while it walks through all that old data to get to the present. Ugh.


On the bright side, I thought of another way that we could get around this. If there is a built-in voice synthesizer (as there is in Excel), my code could append text statements together (rather than appending wav files), and then read the combined text output. That would work. Now we need a way to call a voice synthesizer routine in eSignal and pass a string (sentence for it to read).
Just a thought. For that matter, I could use DDE and output the string to a file and use Excel's voice synthesizer to speak what I want it to say. Now I need to re-learn DDE.


JOHN