Automatic horn signals with ESU v5 decoders was first covered in this discussion. Recently, another option was presented to this author on the groups.io forum that is a different way of looking at the design of the sound slot file. It has its pros and cons as does everything but it is still an intriguing design. One of the differences between the two designs is that the new one depends on the Share1 variable value generated in the prime mover sound slot instead of the Requested Speed value generated by a throttle. Compare figure 1 and figure 2.
Figure 1 New auto horn design
Figure 2 Original auto horn design
Pros
The new design takes only one sound slot since the forward, reverse and stop signals are all contained in the one sound slot file. The original design requires two sound slots since the stop signal is separate from the others.
The new design takes only one sound slot since the forward, reverse and stop signals are all contained in the one sound slot file. The original design requires two sound slots since the stop signal is separate from the others.
Due to this, mapping the sound slot file to function keys is simplified.
Cons
Figure 3 Error indication
Figure 4 The memory issue
There are a couple of issues with the new design.
First, the dependence on the Share1 variable causes a dependency out of your control. If the ESU engineers ever change that value in the prime mover sound slot, adjustments and reloading will have to be done. However, the likelihood of this ever happening is very, very low. So this is a low value con.
Second, the new design calls the sound States one time for both the forward double blast and the reverse triple blast. That means you will have to create a new .wav file for each using an application such as Audacity that manipulates sound files in order to have two blasts for the forward signal and three for the reverse (it would be possible to add additional States for the additional blasts rather than create new .wav files but that is up to the individual).
The original design already has multiple calls to States in the Containers. So no changes there.
Third, as a consequence of creating new .wav files there is a problem introduced. If you didn't notice when you imported the new design into your sound file you probably have a memory problem now. Look at the upper left corner of the LokProgrammer software. See figure 3.
Figure 3 Error indication
Hmmm... an error indication. Where did that come from? Now take a look at the lower right window of the sound pane where the included .wav files are displayed. See figure 4.
Figure 4 The memory issue
When the new sound slot file was imported it brought the new State .wav files with it. Which is exactly what it should do. Due to the size of these new .wav files more memory is required than is available. The only way to fix this is to delete other .wav file from the sound file that are not in use until you get the Current Capacity less than the Maximum Capacity.
Here's the real problem. You will probably have to do this to every sound file you add the new horn design to! While this is not a hugh problem, it can be a pain. It should be mentioned that if you do as suggested above and add additional States in lieu of creating the new .wav files then this should not be a problem.
As you can see, while this is an efficient design from the sound slot and function mapping perspective there are a couple of issues you will have to deal with.
Your call!
If you have an idea for a blog post here, let me know. If I can comment on it, I will or I'll see if someone else can and post it