[R H Steele]

rdamurphy, on 08 March 2014 - 07:05 AM, said:

BTW, for those non-programmers reading this thread, this is how software is written. It's like sausage, if you like sausage you probably don't want to see how it's made... :thumbup3:

Robert

I love sausage (even the vegetarian kind) and don't mind watching being made! Utterly fascinating. What I cannot fathom is how a group of sane people, well versed in mathematics, logic, physics and railroading (the OR Team - bless their souls) can try to decipher what a group of maniacs did more than a decade ago .... and make sense of it. Sometimes, reading the posts - it seems as if they were operating in an alternative reality with different physics and arcane documentation.

[Csantucci]

I have tested release 2103, where Peter added a way to have more chuffs per wheel rotation, and tried it on the MILW 261, adding four other chuff triggers: now I get 4 chuffs per rotation, as it should be. Unfortunately the unregularities in the chuff rate remain. I wonder if this is due to the limited CPU power of my PC.

[RTP]

I was wrong.

The good program to simulate distributions is in:

http://www.billp.org.../ValveGear.html

Cheers.

[midneguy]

Hi again all :)

I finally had a chance to try out the single shot "chugs" using the new triggers tonight, and the results I'll outline below are from using version 2096. Also, this was for a 2 cylinder engine, in this case using modified .sms files for one of my WP GS-64's.

Overall I'm tickled as I think we're on the right track here - the possibilities for steamer sound design will be light years ahead of what was possible in MSTS once everything gets refined I think!

With that said, here's my observations from tonight... Using the four triggers ( 121 through 124 ) I only got "chugs" at roughly twice every driver rotation. I say roughly, because the actual rate was one "chug" at slightly more than every 1/2 driver rotation. So, the triggers aren't quite matched on the "quarters", and are still happening at half the rate they need to be - 2 "chugs" per rotation rather than 4 as it should be for this locomotive. I also noticed that there seemed to be some variation in the timing of the triggers, that is, they didn't seem to happen equally spaced from one to the next. This seemed to be totally random as well, being independent of which particular "chug" was playing. Could this be an indication that the timing of the triggers are being effected by everything else going on in the background? That is, as the load on the system varies up and down (scenery loading, additional sounds being processed, etc) it might be affecting the processing time for the triggers, causing variation in when they occur?

I was curious how this would sound at higher speeds so I went ahead and run up to about 55 mph or a little more, at which point something very odd started to happen. "Chugs" started to be missed totally. I'd describe it almost like being a series of hiccups, where 3 chugs would happen and then silence where the 4th would be expected... 2 more then a silent chug again, 4 chugs then a silent one, and so on. It seemed like one of two things might have been happening - either the triggers were happening fast enough that occasionally one wouldn't even get "fired" (for lack of a better term), or perhaps the sound management system wasn't able to handle the rapid succession of triggers being sent to it causing occasional ones to be missed?

Lastly, a couple other thoughts from my scanning of the discussion since last time I was able to look it over here... The question of "chug" duration with respect to the reverser setting is an interesting one, though I'm not quite sure how this would be handled. From my perspective this isn't something I'd be particularly worried about, at least at this point in time. One thing that would be extremely nice though would be to have a trigger that would be activated dependent on whether the cylinder cocks are toggled open or closed ;)

Anyway, I'm thrilled with where we're going with this - and as always hats off to the OR team :D

[timmuir]

Oh, so this explains why after updating my OR to x2107 Derek's custom sound tweaks for my OR F-1's aren't synchronized correctly anymore. Maybe I better go back to the original .sms.

[Csantucci]

midneguy,
your findings coincide with mine, except that I didn't find that the actual rate was slightly slower than 1/2 rotation, but maybe I didn't look well.
To have 4 chugs per rotation you need to use a version >= than 2102 and use triggers from 121 to 128 (Peter added 12 further triggers to the 4 original ones to accomodate for the various cases).

[gpz]

Midneguy,

Unfortunately you picked the wrong (old) version for testing, the number of triggers are now depend on the number of cylinders (since r2102), and also the timing calculation was totally reworked. It would be worth to make a test with the corrected version instead. (Trigger numbers are now from 121 to 136.)

Couldn't be the reason of the rate being less than 1/2 rotation, that the driver wheel radius set in the .eng doesn't coincide with the 3D model? I have no other idea currently.

But the limitations you describe will surely present in the newer version as well, because these are the limitations of this method. 1: the lack of synchronization, thus the triggering depends on the actual CPU load; 2: When you want to start the next chunk before the previous one had finished, then the new one will either be dropped, or be played with delay. Because of this I think this method might have its good use only at low speeds, and when speed is getting higher, the .sms should switch to the old method. But it needs further testing by you guys, with having considerable experience with steam sound programming.

There is a trigger for cylinder cock open/close, the same as is in MSTS.

[midneguy]

I did have a chance to perform another test with version 2108, utilizing the additional triggers - in this case 121 through 128. With this I can confirm that I did get 4 "chugs" per driver rotation now, and the slight mismatch seemed to be virtually non-existent as well. I also confirmed that the slight "hiccups" in the timing of the pulses is still present on my system also, almost making it sound like the wheels are slipping slightly at times when the pulses don't occur smoothly when they'd be expected. At high speeds I also still had "chugs" getting dropped, or skipped altogether.

I noticed something interesting with one test I attempted. I put a frequency curve in place again on the chug streams, so that the chugs would play faster at faster traveling speeds. After doing this, I was able to run the engine at the higher speeds without any of the "chugs" being missing anymore. Apparently this truly was an issue with not being able to repeat a particular chug sound because the previous instance hadn't finished playing yet. So, that at least suggests that employing either a frequency curve or switching to shorter length .wav files at higher speeds will both cure that problem.

Unfortunately the chug to chug variation from varying CPU workload is pretty bothersome though... If that could be resolved somehow, I think this would be a good method to continue exploring. I regret that I don't know more about the programming side of things, but are there any possibilities for generating the trigger pulses independent of the CPU workload? In my opinion it's not so important that the triggers stay perfectly aligned with 12, 3, 6, and 9 o'clock positions of the driver rotations... If moments of animation and frame rate variations caused the triggers to be shifted, say to 2, 5, 8, and 11 o'clock positions, or other equivalent equally spaced intervals around the drivers, but at least stayed smooth and consistent from one to the next, that's a compromise I could certainly live with.