View Full Version : how to modulate engine sound?
I have the requirement to modulate the pitch of a repeated played sound (for a glider vario) from within a gauge.
FSX has the basic mechanism to do this (i.e. vary the pitch) with wind, engine, prop sounds and its own variometer sound.
WIND - modulated with airspeed (can't change that)
VARIOMETER - modulated with 'VARIOMETER RATE' (non-writeable)
ENGINE (COMBUSTION or PROP) - modulated with what??
i.e. if I want to create a repeating sound varying in pitch but *control* that pitch from within a gauge, is there a *writeable* variable I can write which would influence the sound, e.g. "PROP RPM:2" ??
I'm assuming I'd create a 'spoof' engine, set all parameters like fuel usage and thrust to zero, set the PROP wav to my sound, and then adjust the pitch via the PROP RPM variable.
Any advice/comments MUCH appreciated....
p.s. I've successfully configured the sound for [variometer] but can't seem to unlock the playback from the hard-coded VARIOMETER RATE value, and that's not what I want unless I could write that value from my vario.
friendly bump... any comments?
I've got my modulated sound working fine with a [variometer] section and am writing 'VARIOMETER RATE' to get it to vary the way I want it, but I'm fighting the FSX engine trying to update the variable (with the wrong value...).
I'm hoping 'PROP RPM:n' which *is* a writable variable can similarly be used to affect the prop sound. But I'm a bit puzzled why you could set the prop rpm independently of whatever the engine is doing...
05 Feb 2009, 15:14
The only way I've found to do that is to implement my own custom sound engine using DirectSound.
It seems strange that the prop RPM should be writeable. As for what it represents, well it could either be the output of the reduction gearbox from the engine, or represent the output for a turboprop, where the output rpm could lag the engine speed in a two-piece (i.e. detached N1 and N2 turbines) jet engine.
I'm hoping 'PROP RPM:n' which *is* a writable variable can similarly be used to affect the prop sound.
PROP RPM:n is "writable" only via SimConnect. You cannot "write" to any of the normal A:vars which are by definition "read only outputs" from the sim.
You cannot "write" to any of the normal A:vars
thanks very much for the comments - it's tricky trying to implement all the complex functionality in both XML and C++ but working a lot of stuff out from the documentation and testing.
A: vars read-only in a gauge?? I never noticed 'A:' variables are always read-only to the gauge - I guess that never cropped up because I included the other API's. I wonder why some of them are writeable in simconnect but readonly in the gauge? LOL that's a pretty fundamental fact to know. My glider computer vario gauge has steadily been increasing in implementation complexity, so I've reached the point that I have most of the gauge code in XML, I've written a C++ gauge API DLL that can exchange variables with the XML, plus I've extended the C++ to include the simconnect API to take advantage of some of the capabilities that are only available via that API.
E.g. as this is the 'sound' forum I can can confirm that on the simconnect API you can get the *state* of the sound on-off flag, while within the gauge you only get the 'event' of the sound toggle on/off and *cannot* work out whether sound has just been enabled or disabled...
Programming the variable-frequency tone has been a nightmare, adding DirectSound programming to the FSX gauge and simconnect API's already used, so I've switched horses and am using the built-in FSX support for variable sound. (DirectSound+gauge API+simconnect API *must* be way more complex than should be necessary).
The *only* complexity in the plain FSX technique is how I can persuade FSX to vary the pitch of the sound (I accept using simconnect). There are only a handful of cases, each hard-coded to some user aircraft behaviour (vertical climb, engine speed, prop speed, airspeed) and of those it seems only prop speed stands a chance of being directly controllable.
Given that I'm simming a glider, using prop speed would mean adding a fake engine. A little known side-effect is that FSX removes the possibility of an aerotow if the user aircraft has an engine, so one door opens and another closes. I *can* write 'VARIOMETER RATE' from within simconnect (even though the SDK has it as read-only) and am controlling the sound that way, but I'm a bit uncomfortable as I'm assuming FSX is also trying to update the same variable.
For that matter, if you write PROP RPM, how would FSX know that it shouldn't be updating it? Does FSX update the variable until it sees a single 'write' from user code, and from that point assume it should no longer update that variable??
Any comments/clues help a great deal, as I'm out here in the great lonely world of FSX development muddling along.
06 Feb 2009, 07:35
FSX doesn't know to stop updating its own variables if you choose to, unfortunately. So your sound will likely misbehave as the value is set and then reset.
If you go down the engine route, then I think you will encounter trouble with the prop rpm trying to set it yourself. Instead, look at tieing your sound to the prop rpm or engine rpm and then using an input to drive the engine, like the throttle or prop pitch position. That way you're influencing the variable at the source, not the output, which will simply get overridden.
The trouble in doing it this way is that your joystick axis definitions will interfere. So, you have to use SimConnect to mask those inputs, leaving you free to do it yourself in code.
EDIT: By far the best solution though is to use DirectSound. I've written a directsound engine that reads and understands the FS sound.cfg format and load new sounds from that. So I can completely replace all the FS sound system will custom sounds driven from any sim or gauge variable I like, run from R and V params, just like the defaults. It's been a nightmare to implement though as without hooks into FS's own sound or view systems I can't modulate for distance, view angle or doppler. Sensing when to mute sounds is a pain too. not only do you have to consider the Q sound toggle, but also user sound level preferences, dialog mode, pause, slew, etc.
A: vars read-only in a gauge?? I never noticed 'A:' variables are always read-only to the gauge - I guess that never cropped up because I included the other API's. I wonder why some of them are writeable in simconnect but readonly in the gauge? LOL that's a pretty fundamental fact to know.
I know that the information is in the SDK somewhere, but cannot recall precisely where at the moment... ;)
However, the reason why the facility for writing to some A:vars is really not too complicated...
...it is required for shared cockpit synchronicity.
thanks a lot guys. I can see why some A vars are writeable in simconnect, but didn't understand those vars were read-only in the gauge.
Si your points re input adjustment are well taken, also the comment on DirectSound. On a practical basis I've found that updating VARIOMETER RATE within simconnect on a 'Frame' basis seems to keep the adjustments in front of whatever FSX is doing, so it sounds ok. A bit of a hack though.
vBulletin® v3.8.3, Copyright ©2000-2013, Jelsoft Enterprises Ltd.