Revisiting our sound handling wish list

[G8B4Life]

While poking around the net looking for more things to study, I came across this. ESU is implementing what we were after in sound handling in their decoders but in a way we never dreamed of, and it's impressive.

You only have to watch the first half or so of the video but the rest of the video is still good to watch (that roots blown sound; magic).

I really like what they have done and it should be very easy to implement in software for RailPro.

I can't wait to get one of their new Full Throttle files to study it.

- Tim

[Antoine L.]

Yes that's on Bob Fallowfield's layout. A very fine layout by the way.
And yes, that is something we can have to at some point, our product being upgradeable.

Antoine

[KPack]

I mimic this by using manual notching.  I have the buttons on my first page right at the bottom in the middle, so I can use them without looking most of the time.  However, it'd be great to mimic the prime mover notching by using a system very similar to what Loksound has done here.

We (the Railpro community) have brought it up to Ring and suggested something very similar to this.  Some sort of a button that allows the speed to remain constant while controlling the "speed" of the prime mover with the throttle wheel.  It would be somewhat easy to implement the functionality of it.  Some coding, some testing, etc.  The issue that we may run into is that the Railpro prime mover recordings do not have recordings of the engine cycling up through several notches at a time (say from notch 1 up through notch 4 smoothly).  I'm not sure if that's something that can be done with the current recordings through software manipulation, or if new recordings are needed.

On that note, Railpro could really benefit from GOOD source recordings.  They are getting better, but many of the older prime mover files (645-20, 645 turbo, GE 7FDL-16, 645 roots) are questionable.  The newer ones like the Alco 539T and EMD 567 are better, but could still benefit from some improvement.  The test file I have of the new GEVO-12 is very nice indeed, just needs some tweaking.  The GEVO-12 was submitted by a fellow Railpro user who recorded a working (pulling a train) locomotive through all 8 notches up and down.  That's what we need more of!  I'm sure there are Railpro users who have access to museums, short lines, etc that could obtain some VERY nice recordings.  Ring Engineering can only do so much at one time, and waiting for them to record and develop new prime mover sounds will make for a long wait.  The more we can do ourselves the sooner we will have top-shelf sounds.

Tim, when you get one of those Full Throttle files, let us know what you find.  It will be helpful to know how they went about it so we can form ideas and present them to Ring.

Really nice layout in that video BTW.

-Kevin

[William Brillinger]

I'm not so sure that locking the speed of the loco and then adjusting the sound with the dial is the way to go, but it's an interesting idea.
The units in that video sure do sound great!

I agree with Kevin, some better recordings especially for the older EMD's will go a long way to improving RailPro's ability to mimic real world sound performance using just the notch up and down buttons. Add a coast button and and I think RailPro's sound abilities will be right there.

Tim Ring did indicate to me back in November 2015 that he has new recordings for the EMD 645's.

Hopefully they will come soon.

I think I have come around to Kevins approach regarding momentum though. Turn the momentum effects nearly off and just use the knob to mimic it.

[Alan]

Since it is a wish list....

Why not software it to be like the real thing? Enter the tonnage and HP and then the knob becomes a control stand. Let the software work out the motor speed.

[G8B4Life]

Unfortunately Alan, that one would be hard to work out because of the complexities of train dynamics and our model dynamics. I'll give a couple of examples. This is probably going to be a bit boring for most but in the interest of prototypical operation...

I don't have load tables for US locomotives so the figures I'll present are made up but the principal and theory is the same.

A SD70Ace with say 4300hp can pull say 1500t on the flat.  Two of them with combined 8600hp could pull 3000t on the flat. That's easy.
Now we thow in grades. Those two SD70Ace's can only pull say 2300t up a 1% grade. If we though in curves as well the tonnage is further reduced. This is all still pretty easy.

Now we get a bit harder. Suppose we have an SD70Ace and a GP50. The SD70Ace we know has 4300hp and can pull 1500t. The GP50 let's say is 3600hp and can pull 1000t. Most people would think that we have 7900hp and can pull 2500t on the flat. Wrong. The SD70Ace develops it's max tractive effort at say 21mph but the GP50 develops it max tractive effort at 15mph. What this means is that the GP50 cannot pull it's max rated load at the same speed as the SD70Ace so the tonnage that can be pulled by both is actually say 2100t. The prototype has all sorts of tables that state what tonnage can be pulled by what combinations in what territory.

What this means, to bring the post back to RailPro is that pure hp and train tonnage can be meaningless unless the loco's are all the
same in their capabilities. I really don't know what RailPro could do with that information. RailPro's load sharing seem to mimic the above dynamics of differing capabilities well but even that can probably only go so far. Until our models start becoming equipped with drives that are not directly coupled between the motor and the wheels we'll never properly have prototype dynamics.

I'd love to see a proper 8 notch throttle with proper loadup/ rundown / coasting and proper braking. I almost finished reworking a design for one years ago.

- Tim.

[William Brillinger]

....Not to mention the issues of selective compression of train size and tonnage. It would be nearly impossible to automate the dynamics of a train on the throttle in a way that would 'feel' right on every layout.

But, given smooth transitions from Notch 1 to 8, [Notch Up], [Notch Down], and a [Coast] button, it would certainly be easy to replicate the behaviour.

[Alan]

Tim,

I am probably bias because I write software (part of day job) that works with relational data points and tables. I'm sure the code could be written to accurately (good enough) recreate actual train movement. Getting the layout data points would be the real challenge. I am implementing an occupancy detection system that is much more granular than most layouts have - 33 detectors in 150' main. It reports train direction as well. If a RP 2.0 system did exist that could do the math, I may have a detection system that could feed it the necessary curve/grade/direction info.

Manually controlling the train while also manually controlling the sounds seems like a half baked solution to me. Better than no independent control I suppose.

Just dreaming 

[Alan]

The occupancy detection I referenced earlier:

[G8B4Life]

No problems with dreaming Alan, I'm still dreaming too. More on that later.

I do have to say, I've read your detectors and breakers. Nice job on them (though you did have to choose just about the most inaccessible IC in this country for the breakers).

Now, unless I'm reading your thinking wrong, it sounds like what your describing is having the software determine what notch (sound) it should be in regardless of throttle setting.  That could possibly be done by monitoring the current draw but I imagine you'd get wildly different experiences on grade vs flats. Load tables, inputting the tonnage (hp could be predefined when setting up the LM) and data points around a layout would help that but I think you might be the only who would implement it. Interesting concept though.

My dream? I'm still dreaming of my almost perfect system. Back in the day when I was experimenting with torque couplings I had an almost perfect system; I could physically be in notch 8 (the motor spinning at full rpm) with the train at walking pace with a heavy load behind it. Speed matching or load sharing was completely automatic as part of the drive train. If only I had sound and a coast button back then I would have had it.

- Tim

[Alan]

Yep, you are right. Practical is a word we dare not use. My detector system and your torque transfer mechanics are not practical for the masses. It is interesting however to give thought to the different approaches to the problem and possibly their synergies.

If someone had dared stating RP's capabilities the day DCC was launched they too would have been considered nuts. But look at where we are now.

The root problem as I see it is one of coupling. The coupling of sound and movement is not right today although we are fortunate to have at least some coupling. I question if manually controlling each half of the equation is the best approach to solving the problem. If the intent is to create an illusion, isn't that illusion seriously undermined when the user is mentally calculating "what adjustment should I make to increase the realism?" Shouldn't the mental work be "do I need more or less throttle?" Seems like a problem that can be solved given today's technology.

PS. the breaker IC is of the generic class "hot swap controller". There are many on the market. I dialed in on the LTC1153 only because the datasheet presented as an example the exact circuit I needed. I didn't design anything. I used their schematic and then tweaked it's trip point and reaction speed to suit my needs. How to make these two adjustments were also clearly explained in the datasheet.

[G8B4Life]

Hello all,

Long post. Please bear with me.

ESU released their updated sound handling features a week ago so I've done some serious studying of it to see how it all worked to see what ideas we could take away for improved sound handling in RailPro. I also studied RailPro's sound as well, which is at the bottom of the post. There is a document on ESU's new Full Throttle features on their website (http://www.esu.eu/en/downloads/instruction-manuals/digital-decoders/) if anyone wants to read further but I've summarised it below.

Drive Hold:

The key to it all. When this button is pressed, the motor will remain at a constant speed, while the sound can be controlled independently from the motion with the throttle knob.

Run 8:

The Run 8 function will increase RPMs from wherever you are, all the way up to Notch 8 and hold. Once the function button is pressed, the sound is disengaged from the speed. Using the throttle knob you can now speed up or slow down with the sound remaining constant, at full throttle.

Coast:

Opposite of Run 8. Prime mover drops to idle and sound is disengaged from speed. The throttle can now speed up or slow down the train with the prime mover at constant idle.

Brake (independent):

Supposed to work like an independent brake, Uses a function to slow the train down and play the sound file of the independent brake.

Dynamic brake:

Mimics a dynamic brake. This was actually a part of the ESU's decoders before but has been upgraded to better consist and play sounds with dynamic braked and non dynamic braked loco's. The dynamic brake actually gradually slows the train down and plays sounds the proper way for a dynamic brake being used (unlike RailPro where you can activate the dynamic brake no matter what notch your in and stay in that notch).


Sound handling: This is just for a bit of background info, to show what we're missing on the creation of sound in RailPro. I've always been impressed by how sounds are made up in LokSound.

Everything is flow chart based, one simply places sounds in a container and connects them with logic. It is much more free than the ridged way in RailPro, eg, in Loksound a loop can have as many files as needed, not just three (as per user created loops in RailPro).


Horn flowchart sample

The above images shows a horn and gives a good example of more than 3 files being used to control the horn sound. The logic shouldn't be hard to follow. Each tan coloured container contains a sound to play. The container that says Loop could also be a container that loops say 4 files to make one "loop". All the prime mover notch's are like this, 4 separate files as played to create one loop of the notch sound.


567C flowchart sample

This is the greatly zoomed out flowchart for the 567 prime mover (from the Full Throttle video I posted in an earlier post).It looks complicated but it's really just simple logic (as mentioned above, each notch-loop is comprised of 4 files. This makes reacting to notch changes much more dynamic and realistic).  I really wish I could post a video of how well this works in controlling sound but I don't want to waste Bill's server diskspace and I don't do YouTube.

Of note, there are 120 separate sound files (99.81 seconds worth) to make up this prime mover compared to RailPro's 31 files (unknown seconds) to make up the 567. Actually, the RailPro prime mover file appears to contain the random compressor, spitter and hiss sounds so it is probably 24 sound files for the prime mover.

RailPro sound: I also spent a fair bit of time studying this. I now know the structure of the sound files and how they are created, though I don't yet understand what the end result of this creation achieves. Basically it appears that when creating a sound file a lot of the sound information is lost/thrown away to turn that CD quality sound (16 bit 44.1Khz PCM) into something that the LM can play. My guess at this time is 8 bit PWM though I don't know for sure. I do wonder about that claim of "HD" in "Rail Sonic HD" now.

I'm still studying RailPro and may have more to report later.

Don't think that I'm bashing RailPro here, I love it but we can have better and the more info I can provide everyone here in comparison to the best (in this case Loksound, and yes they are the best in sound) and how RailPro does the same the more we have to take away to RE for improving RailPro.

- Tim

[William Brillinger]

Drive Hold:
The key to it all. When this button is pressed, the motor will remain at a constant speed, while the sound can be controlled independently from the motion with the throttle knob.

I have to say, Drive Hold concerns me. I know there is a panic button, but I don't like the idea of disconnecting the motion from the knob.  In fact I've come to the conclusion that I don't even like momentum effects any more. Like Kevin, I prefer to feather the speed control to create my own effect here.

If Ring engineering would add the coast feature, and fix manual notching to do smooth transitions, I think RailPro users could easily emulate what ESU has done here.

[KPack]

Tim - That is some really great information there.  I've always wondered how Loksound went about their sound files.  I like the flowchart and the fact that you can use more files than just three for a loop.  That seems to be what Railpro is missing when it comes to smooth throttling up and down.  A new software program for Railpro could allow something like this.  The problem would be could Ring Engineering get it out in a timely fashion. 

I'm curious as to how you figured out how many files were in the Railpro prime mover file?  I've always wondered that.  And I've always been curious as to whether or not the sound files actually retain their original 44.1 kHz, 16-bit PCM sound or if it is downgraded. 

Here's the issue I see....the Railpro modules only have so much space on them and I wonder how many additional recordings would be able to fit.  I'll be honest, I don't think that full 44.1kHz 16-bit PCM WAV files are completely necessary here.  Yeah, it's nice to say that it uses "full CD-quality sound", but that sound really doesn't translate through the tiny speakers we use.  Even my nicer set-ups with four speakers don't sound anywhere near as nice as desktop computer speakers.  So why spend the valuable space on a sound format that you probably aren't getting the full benefit from anyway?  Personally I'd much rather have Railpro use something like MP3 and allow a TON more sound files to be used on the module.  That means way more recordings for prime mover files so smooth transitions are a possibility, multiple coulper clank and release sounds for random playback when the button is pressed, way more variety on air release and spitter sounds, etc, etc.

I agree with Bill regarding the "drive hold" function.  I don't like the idea of taking motor control away from the knob.  But a "coast" button would be great to allow the prime mover to spool down while the train is still moving.  Or I'll just continue to use manual notching....just need the transitions through multiple notches to be better.

-Kevin

[G8B4Life]

I can see the points for both types of parties; the concern being taking away movement control from the throttle knob, and the enhancement being the throttle knob being much more responsive to give more dynamic control of nothing up and down. You can easily validate the enhancement to RailPro by comparing how responsive notching sound is using the knob and then using the manual buttons. The buttons take far more time to go through all the motions.

Kevin, It was actually quite simple to work out how many files were in the prime mover file; once I had worked out the structure of the sound files (which wasn't as simple) it was just a matter of looking at the correct location that holds the value for the number of files.

The sound is downgraded as mentioned, I'm just not sure by how much and to what format. The LM-2's have 4 Megabytes of memory (which is the same as Loksound by the way), plus whatever capacity the microcontroller has built in, which would only be a few Kilobytes.

Now, as it stands the current 567 prime mover file is about 1.7 Megabytes. This leaves just over 2 Megabytes for everything else, including I believe the LM-2 program and picture. None of these are very big.

MP3's could not be used, even if the code for the microcontroller to play them could be written. MP3's have information in the header that has to be processed which causes a slight delay in playback. You are correct though "CD" quality is not needed, even if just for file size reasons (full 16 bit 44.1Khz audio would give about 47 seconds of sound for 4 Megabytes) ; It might surprise some but those beautiful Loksound sounds that you all heard in the Full Throttle video; created from 8 bit 15.6Khz wav files. Of course, the IC that processes and plays the sound is a big governing factor in sound quality. I've tried to identify that IC on the LM-2 board but I've not been successful.

Now that I've played with RP and done a bit of study I see a lot of room for improvement in the creation and handling of sound in RailPro. Hopefully RE will agree and create a more flexible and open way of doing it.

Oh, and you all might find this interesting, large (equals long download) is a relative term for RailPro. As mentioned the prime mover file for the 567 is only 1.7 Megabytes (1,738,987 bytes) so why does it take so long to download over the internet? RP files are downloaded from RE's server 401 bytes at a time, roughly two times a second. If we round that up slightly we get 1 kilobyte per second, that's right, almost 4 times slower than the maximum speed of my old dial up modem! This could be because as the files are downloading they are being copied to the HC at the same time which sounds about right for the speed, or RE is limiting the speed. Either way there is no need for this, files should be able to be downloaded at full internet speed and then loaded to the controller. Hopefully with the upcoming CI-1 this will be the case.

- Tim