[Weter]

Yes, the start/stop of motor procedure is very "raw" now, in context of sound accompaniment.
So, it's desirable very much, if it would be enhanced.

[ErickC]

 roeter, on 20 June 2021 - 01:23 AM, said:

The activation / deactivation range is based on the 'cutoff' range, that is the range at which the reduction of the volume is such that the volume has reached 0.
This makes sense as it is just a waste of capacity to keep soundstreams active if you don't hear them anymore anyway.
So any changes to the activation range has to be combined with a change to the 'cutoff' range (or better, the 'cutoff' range is the main parameter, activation range is derived from this). A fixed change to the cutoff range is not desirable, it could lead to problems on busy routes. Perhaps the cutoff range could be set up as a user or route variable.

The way that MSTS handled it was that it scaled the cutoff range to the activation/deactivation distance. Would it be possible to simply implement it this way?

Quote

Presently, the engine sound is controlled by 'variable2', which is scaled between min-RPM and max-RPM.
Some years ago I introduced a test using a new 'variable4', which was scaled between 0 and max-RPM. The drawback of this was that all scaling values would have to be recalculated and all sms files altered accordingly. This was met by the community with a distinct lack of enthousiasm, and so the whole idea quietly went off stage through the back door.
However, somewhere on my list there still sits the (re)introduction of a 'variable 4', but set up such that the present values in the sms files can be retained, and the program itself calculates the proper scaling values between 0 and max-RPM, based on the defined 'variable 2' values and the min-RPM.
This would not only tackle the problem discussed here, but would also allow AI engines to be switched off and on, with proper sounds, e.g. when stabled in timetable pools.

Regards,
Rob Roeterdink

I think this is a great idea, and my suggestion is to make variable 4 an RPM variable, not a percent variable. Calculating percentages for each RPM value is really tiresome, and I would much rather the X-coordinate be an RPM value, just like the parameters in the ORTS diesel block. This would be particularly helpful when making sounds for related locomotives that have different maximum or idle RPM values and the same engine, for example, the 567B on a GP7 has a maximum RPM of 800, while the 567C on a GP9 has a maximum RPM of 835. The difference is very audible. At the present, I either have to make two separate SMS files or set the maximum RPM on both engines to 835 and use the throttle RPM tab to regulate it down to 800 for the 567B. If the SMS instead interpreted the RPM value directly, there would be no need of either strategy.

Another prime example is the 567D2 vs the 567D3A. The 567D2 should idle at 275 RPM and run at 835 RPM in Run 8. The 567D3A idles at 318 RPM and tops out at 900. The engines should otherwise sound identical. It would be much easier if a variable 4 table looked like this:

				FrequencyCurve(
					Variable4Controlled
					CurvePoints ( 3
						001			   139.3
						275			 38306.3
						900			125366.0
						)
					Granularity ( .001 )
				)

Remember that part of building any diesel sound set is to calculate the exact RPM of each clip by counting exhaust pulses and then calculate the frequency curves by dividing the idle RPM (for the first set of coordinates) and the maximum RPM (for the second set of coordinates) by the calculated RPM of each clip, so we're going to know where the RPM needs to be anyway.

The math required to "convert" an older SMS is easy. Since you should only have two coordinates in the frequency curve for each clip, one at 0.0 and the other at 1.0, all you need to do is change the 0.0 to the idle RPM and 1.0 to the max RPM. Calculating the frequency below idle is equally simple, in the above example, to avoid dividing by zero, I simply made the first coordinate at 1 RPM, divided 1 by 275 (the idle RPM) and then multiplied that by the frequency value (38306.3) of the idle RPM. 1 RPM should be close enough to 0 to get an accurate sound below idle.

[hugoakio]

 roeter, on 20 June 2021 - 01:23 AM, said:

A fixed change to the cutoff range is not desirable, it could lead to problems on busy routes. Perhaps the cutoff range could be set up as a user or route variable.

It would be a great add

[Csantucci]

I'm investigating a more limited solution, and it seems to work. I've always read only about complaints about the player train. So I tried modifying the sound activation/deactivation distance only for it, setting it to the maximum between 2000 meters and the train length + 50 meters, provided that the activation/deactivation distances in the .sms file are higher than such maximum. I created a 2600 m long train and put at its end a GP38 with a modified sound (engine sound with intro part, plus activation and deactivation distance higher than train length); I increased the viewing distance to a value higher than the train length, and started the game. The sound debug interface showed that the GP38 sound was playing when being in camera 2; switching to camera 3 the intro part of the sound had been already played, and the loooped part was playing. Repeatedly switching from 2 to 3 didn't cause problems.
I am not keen in altering parameters for sound sources of all types (to avoid too high computing load) neither to make available to the users another configuration parameter.
So I have the intention to insert this first in ORNYMG, and if it finds acceptance, to propose it also for the official OR versions.

[Csantucci]

This is now available in ORNYMG rev. 100.

[hugoakio]

 Csantucci, on 24 June 2021 - 12:40 PM, said:

This is now available in ORNYMG rev. 100.

Thank you very much Csantucci! Problem solved here.

[Csantucci]

This should be now available also in the official Unstable release.

[Weter]

Hello.
Just seen another issue:
the sound of horn have been cut-out just near the end of 40-car train.
Version T1.3.1-1890

[QJ-6811]

I notice in the latest releases that the status of "stop"starting"running"stopping" no longer works as before?
This includes the "cab signalling". I mainly mean the cab and sound triggers, which functioned well in an older release, also in combination with Shift-Y and Ctr-Y.
Is this a 'bug' or have all these statuses changed in the newer release?