Project XRSound 1.0 and Updated XR Vessels Beta Testing

[dbeachy1]

Hi all,

XRSound 1.00 Beta-1 and new XR vessel beta versions are ready for public beta testing! In addition to providing a C++ API for vessels to use, XRSound also provides over 450 available, fully configurable, default sounds and voice callouts for all Orbiter vessels and add-on authors to use via the XRSound.dll Orbiter module. In addition to the global XRSound.cfg file that configures default sounds for all vessels, you can also edit or create Orbiter vessel-class-specific config files, such as the included XRSound-DeltaGlider.cfg, etc., that assigns default sounds to vessel-specific animations and landing gear without requiring recompiling the vessel or doing any coding. I am still working on writing a proper XRSound user manual and updating the XR Flight Operations Manual for XRSound, but for now, XRSound and the new XR vessel versions are ready for public beta testing.

Special thanks to Loru for creating the XRSound logo and a brand-new ambient music track that by default plays in external views in space (details below). :tiphat:

XRSound 1.0 Beta-1 features include:

• Automatically adds default sounds for any Orbiter vessel that defines thrusters -- not just XR vessels! You can also manually assign sounds to any vessel class via its XRSound-<vessel class>.cfg file; e.g., XRSound-DeltaGlider.cfg.
• Each sound or group of sounds is fully configurable via XRSound.cfg and optional Orbiter vessel class-specific config files, or via the XRSound SDK (included).
• Includes 450+ sound files, including all XR voice callouts by actress Sally Beaumont and 141 ATC callouts from STS-114 and STS-121 featuring CAPCOM Julie Payette. (These default ATC callouts are a combination of all three STS sound packs currently on my Web site.)
• Add-on authors are free to use any of the sounds in their own vessels (just please don't redistribute the files).
• Includes new Solar Serenity ambient music track created by and licensed from Grzegorz Lorens ("Loru" here on Orbiter-Forum) that plays in external views in space by default. This is configurable like any other sound. (For a lossless version of Loru's Solar Serenity, take a look here.)
• All default sounds are fully configurable, including:
  • Air conditioning
  • Audio greeting voice callout on simulation start
  • Music in external views in space
  • Wind effects while landed in an atmosphere
  • Main engine sound
  • Hover engine sound
  • Retro engine sound
  • RCS sounds
  • Switch on / Switch off clicks for RCS and AF Ctrl changes
  • RCS mode change voice callouts ("Rotation", "Translation", "Off")
  • AF Ctrl mode voice callouts ("Off", "Pitch", "On")
  • Crash sound
  • Hard landing sound
  • Tire chirp on touchdown for vessels that define landing gear animation ID via their XRSound-<class name>.cfg file. [You can set `LogVesselAnimations = 1` in XRSound.cfg to log the animation IDs for all vessels as you activate each animation.]
  • Tires rolling sound; volume varies by ship velocity
  • One additional custom engine sound per vessel (e.g., the SCRAM engines in the stock DeltaGlider-S). Configurable via a given vessel class's XRSound-<vessel class>.cfg file.
  • Wheel brakes sound
  • Takeoff and landing voice callouts ("100 knots", "Wheels up" / "Liftoff", "You are cleared to land", "Warning: gear is up", "Touchdown", "Wheel stop", etc.)
  • Wind sound and plasma sound in flight; volume varies by dynamic pressure
  • Autopilot on / off sound tones
  • Ambient sounds configurable by pointing to a folder in XRSound.cfg; twelve ambient sounds are included by default, but there is no limit to the number of ambient sounds supported. Minimum and maximum playback interval is configurable.
  • Altitude voice callouts
  • Docking distance voice callouts
  • Docking and undocking voice callouts and sounds
  • Docking radar sounds whose beep interval varies by the distance to the docking port
  • Mach voice callouts ("Mach 1", "Mach 2", "Mach 27 Plus", "Subsonic", etc.)
  • ATC sounds played at random at configurable intervals from a specific folder. Like all other sounds and groups, the folder can be changed at runtime via an SDK call, and may be configured via XRSound.cfg or XRSound-<vessel class>.cfg otherwise.
• The new XR versions now use XRSound, and therefore no longer need to bundle their sound files with each vessel anymore: all sounds are included with the XRSound download.
• Can add sound events to any existing Orbiter vessel's animations simply by editing that vessel's class's XRSound-<classname>.cfg file. Includes .cfg files for each of the default Orbiter vessels.
• Includes C++ SDK for add-on authors to use in their own vessels (the new XR vessel versions use it).
• You can replace or disable any or all of the default sounds via the XRSound SDK or XRSound.cfg.
• XRSound.lib is statically linked; no need to bundle Visual Studio redistribution files with an add-on in order to use XRSound, and add-ons that link with XRSound.lib can still run without XRSound.dll installed.
• No limit to the number of sound slots that vessels may use.
• No limit to the number of vessels in the simulation.
• No limit to the number of ATC radio chatter files for a given "frequency" (i.e., folder): you just configure the ATC folder in your XRSound.cfg, and any sound files in that folder are played at random for ATC chatter.
• Parameters for minimum and maximum times between ATC chatter playback are configurable via XRSound.cfg.
• Uses irrKlang Pro sound engine internally, which supports the following sound file formats:
  • RIFF WAVE (*.wav)
  • Ogg Vorbis (*.ogg)
  • MPEG-1 Audio Layer 3 (*.mp3) [via ikpMP3.dll plugin, included]
  • Free Lossless Audio Codec (*.flac) [via ikpFlac.dll plugin, included]
  • Amiga Modules (*.mod)
  • Impulse Tracker (*.it)
  • Scream Tracker 3 (*.s3d)
  • Fast Tracker 2 (*.xm)
  • Additional sound formats may be supported by dropping irrKlang plugin DLLs into $ORBITER_ROOT.
• Refer to the comments in $ORBITER_ROOT\XRSound\XRSound*.cfg files for full details about configuring XRSound.
• Refer to the comments in XRSound.h (used with static library XRSound.lib or XRSoundD.lib) in $ORBITER_ROOT\Orbitersdk\XRSound for more information about the XRSound API.

XRSound future (potiential) features:

• XRSound MFD to set different XRSound parameters at runtime.
• 3D positional audio (the underlying irrKlang Pro sound engine used by XRSound supports it).

Here's a simple XRSound SDK example:

#include "XRSound.h"
 
// could use #define for IDs instead since sound IDs are just signed integers, but an enum is cleaner
enum MySounds
{
    SystemReset    // value 0
};
 
class MyVessel : public VESSEL4
{
    ...
    XRSound *m_pXRSound;
    bool bResettingTheSystem;
};
 
void MyVessel::clbkPostCreation()
{
    m_pXRSound = XRSound::CreateInstance(this);   // create sound engine instance for this vessel
 
    // load a custom sound for this vessel
    m_pXRSound->LoadWav(SystemReset, "XRSound\Default\System Reset.wav", XRSound::Radio);  // returns false if file not found
 
    // disable the default "100 knots" voice callout
    m_pXRSound->SetDefaultSoundEnabled(XRSound::OneHundredKnots, false);   
 
    // replace the default docking voice callout with a custom one that resides in $ORBITER_ROOT\MySoundsFolder
    m_pXRSound->LoadWav(XRSound::DockingCallout, "MySoundsFolder\My custom docking callout.mp3", XRSound::Radio);
}
 
void MyVessel:::clbkPreStep(double simt, double simdt, double mjd)
{
    if (m_bResettingTheSystem)
    {
        // play our custom sound: don't loop it, and use max volume
        m_pXRSound->PlayWav(SystemReset, false, 1.0);   // returns false if play fails
        m_bResettingTheSystem = false;      // so we don't keep looping it (although calling PlayWav if a sound is [I]already[/I] playing can only change its volume or loop settings: it will not stop and restart it.
    }
}
 
MyVessel::~MyVessel()
{
    // as with any other allocated member variables, always remember to clean up the XRSound engine instance in your destructor! :)
    delete m_pXRSound;
}

Of course, you can also load a new sound into the same sound slot at any time; if a sound is already playing in that slot, it will automatically be stopped when LoadWav replaces it:

if (m_pXRSound->LoadWav(SystemReset, "My new message.ogg", XRSound::Radio))   // does sound file exist?
    m_pXRSound->PlayWav(SystemReset);    // play the sound using defaults of loop = false and max volume

One important thing to note regarding performance is that LoadWav is lightweight and does not actually load the sound data into memory: it simply 1) verifies that the file exists and is readable, and 2) saves the file path and playback type in the master sound map in memory for this vessel. Sound data is only loaded when it is played, and it automatically released when no longer needed: this is all managed by the underlying irrKlang Pro sound engine.

Refer to $ORBITER_ROOT\Orbitersdk\XRSound\XRSound.h for more information about the SDK. There will be more documentation coming in the XRSound user manual before version 1.0 ships.


EDIT:
XRSound has now shipped, so these links have been updated to the public release versions.
Beta Release download links:

• XRSound 1.00
• XR1 1.15
• XR2 1.10
• XR5 1.13

Note regarding the new beta XR vessel versions:

• In addition to porting the new XR vessels to XRSound, braking performance issues in Orbiter 2016 have now been resolved, although you still need the parking brakes to keep from "sliding around" if you land on a slope. Please let me know if you notice any more braking performance issues.

EDIT:
Here's a video I recorded of the XRSound BETA-4 version with Orbiter's default "Welcome to Orbiter 2016" playback scenario -- this is using all default XRSound settings:

Installation:

• Unzip the download file to your $ORBITER_ROOT folder.
• Bring up the launch pad, click Modules, and enable the XRSound module in the Miscellaneous section.
  

XRSound does not save any data to or read any data from the scenario file. This is an early beta, so please let me know if any default sounds are too quiet / too loud / don't play at the right time, etc., and (if you wish) please test the default Orbiter vessels and third-party Orbiter vessels in addition to the new XR vessels. With the XR vessels, please let me know if you hear any "double" sound effects, which means that I missed disabling that XRSound default sound in the XR code (since the XRs already handle almost all their own sounds).

One final note: if you are running OrbiterSound, before testing XRSound you should disable OrbiterSound by unchecking it in the Modules section of the launch pad: otherwise, you will have two modules playing default sounds for vessels, and they will conflict.

Thanks for your help beta testing. Happy Orbiting! :tiphat:

EDIT:
As of the BETA-2 XR vessel versions, UMMU, which crashes to desktop on egress while landed or performing crew transfer in Orbiter 2016 anyway, is no longer used by XR vessels. MMu functionality will be re-enabled if and when a suitable MMu replacement that works with Orbiter 2016 is available.

EDIT:
Beta-3 uploaded 15-Feb-2018 w/same download links as above. Details here.

EDIT:
Beta-4 uploaded 18-Feb-2018 w/same download links as above. Details here.

EDIT:
XRSound Beta-5 uploaded 19-Feb-2018 w/same download link as above. Details here.

EDIT:
XRSound 1.00 and the new XR vessels have SHIPPED, so these download links have been updated to the public release versions. Thanks again for all your help beta testing!

 

[Mojave]

This is some great news! This was a pleasant surprise through and through.

Ain't even Tuesday.

 

[Xyon]

Amazing work dbeachy1 and Lori! Many thanks for sharing!

 

[Face]

One final note: if you are running OrbiterSound, before testing XRSound you should disable OrbiterSound by unchecking it in the Modules section of the launch pad: otherwise, you will have two modules playing default sounds for vessels, and they will conflict.

Hurrah for the heroic effort!
Let the fight begin and see who will be the last sound standing (wave?). :lol:

One question, though: will you open the source so people can continue using it after you've lost interest, or think that the next Orbiter version is not "stable" enough to be worth making patches? Or will developers simply have the choice between 2 - perhaps conflicting - closed sound platforms?

Thing is: if the conflict is baked in so deep that you can't run scenarios with vessels from both "camps" properly, it might split the community severely.

 

[Xyon]

I for one welcome our new sonic overlords.

 

[Mojave]

it might split the community severely.

Well, if this ends up being the case... I'll have to jump onto the XR sound bandwagon. Hurray for sound that follows when you switch window focus!

 

[dbeachy1]

One question, though: will you open the source so people can continue using it after you've lost interest, or think that the next Orbiter version is not "stable" enough to be worth making patches? Or will developers simply have the choice between 2 - perhaps conflicting - closed sound platforms?

Thing is: if the conflict is baked in so deep that you can't run scenarios with vessels from both "camps" properly, it might split the community severely.

Well, it's not a "conflict" per se, except that you get two sets of default sounds, which is noisy. However, XRSound is fully configurable, and you can configure it such that it only plays sounds for specific vessel classes and no others, which means you can run both XRSound and OrbiterSound at the same time. Details at the end of this post.

As for open-source, I've considered that, and although I don't want to open-source it yet, I would certainly open-source it before walking away from it. Speaking personally, it's fun to work on hobby projects and have full control of them, and if I open-source them, it feels like I would lose that.

My primary motivation for creating XRSound was in fact the thing you mentioned: previously, the XRs were reliant on two sets of abandoned software: OrbiterSound and UMMu, and now they only rely on one (UMMu) don't rely on any as of the new BETA-2 XR versions. My secondary reasons for writing XRSound were:

• No longer needing to bundle all the XR sound files with each XR vessel, which reduces the download size of each XR vessel and makes them simpler to package and deploy.
• The ability to finally play back any of my STS ATC files from one "frequency" instead of having to choose just a subset of them: I always wanted to have access to all 141 of my STS ATC messages at once while in flight, and now I can.
• Allowing the community to use any or all of Sally Beaumont's voice callouts and not just restricting them to XR vessels anymore.
• No longer being limited to 60 sound slots per vessel, which was a real pain while developing the XR vessels (lots of slot reuse).
• And last but not least, it is a fun project.

As for porting between the two, I was able to port the XR vessels from OrbiterSound to XRSound in a day. Both XRSound and OrbiterSound use integers for sound IDs, and there are similar calls (LoadWav, PlayWav, StopWav, etc.) and sound playback types (BothViewFar, Radio, etc.) on both, so that made the port straightforward.

In any case, since XRSound is fully configurable, if a user wants to run both XRSound and OrbiterSound at once, you can configure XRSound to only play its default sounds for XR-class vessels as follows:

1. In $ORBITER_ROOT\XRSound, copy XRSound.cfg to XRSound-DeltaGliderXR1.cfg, XRSound-XR2Ravenstar.cfg, and XRSound-XR5Vanguard.cfg.
2. Delete or move XRSound.cfg out of that folder.
3. Delete or move XRSound-Atlantis.cfg, XRSound-DeltaGlider.cfg, XRSound-DG-S.cfg, and XRSound-ShuttleA.cfg out of that folder.

Now XRSound will only play default sounds for the XR-class vessels since you deleted or removed the global XRSound.cfg and the .cfg files for the default Orbiter vessels. You can now run both XRSound and OrbiterSound at the same time, and XRSound will only play default sounds for those vessel classes that have .cfg files in $ORBITER_ROOT\XRSound. You may still have a few "duplicate" sounds in the XR vessels, such as docking radar sounds, but you can further tweak the XRSound-*.cfg files to prevent XRSound from playing those specific sounds, and so just listen to the OrbiterSound versions. I have not tested that yet, but that is the intention, and if there are bugs with that, I will fix them.

TL;DR: A user can run both XRSound and OrbiterSound at the same time if they are so inclined by making the XRSound-*.cfg files changes shown above. Or you can just check / uncheck the corresponding sound plugin in the Orbiter launch pad's Modules section whenever you switch between vessels that require XRSound or OrbiterSound. :thumbup:

 

[Interceptor]

This looks awesome dbeachy,but one question do the newest XR vessels have Xsound built in already,or do we have to download the Xsound addon seperatly,and add it to each XR vessel?Thanks for your hard work..

 

[dbeachy1]

You have to download XRSound separately: it is 177 MB zipped and includes all 450+ sounds as well as the XRSound.dll plugin module.

 

[Interceptor]

You have to download XRSound separately: it is 177 MB zipped and includes all 450+ sounds as well as the XRSound.dll plugin module.

Does your Xsound addon include premade sound configs to use,or change for all three of the XR vessels?

 

[dbeachy1]

It has pre-made sound configs for each of the default Orbiter vessels (look in $ORBITER_ROOT\XRSound), but the XR vessels don't need any custom .cfg files because all their custom animation sounds are already handled via code in the XR vessel DLLs. However, there are certain default sounds, like engines, RCS, docking radar, wind, reentry plasma, tire noise, wheelbrake noise, etc., that are still handled by the XRSound.dll plugin, which will look in the global XRSound.cfg file for those settings if that particular setting does not exist in the XRSound-*.cfg file for that vessel class.

 

[Interceptor]

Thanks dbeachy looking foward to trying it out this evening.

 

[dbeachy1]

Update: BETA-2 versions of XRSound and XR vessels uploaded (same download links). Changes are:

1) Fixed wrong failed EVA error message being played in the XR5 via the docking port, and
2) Updated XR vessels to no longer use UMMu in order to to prevent crash-to-desktop in Orbiter 2016 when attempting to egress crew member while landed or transfer crew member. MMu functionality will be re-enabled if and when a suitable MMu replacement that works with Orbiter 2016 is available.

 

[Face]

2) Updated XR vessels to no longer use UMMu in order to to prevent crash-to-desktop in Orbiter 2016 when attempting to egress crew member while landed or transfer crew member. MMu functionality will be re-enabled if and when a suitable MMu replacement that works with Orbiter 2016 is available.

Smells like an XRMmu is in work :lol: .

---------- Post added at 09:50 ---------- Previous post was at 08:13 ----------

As for open-source, I've considered that, and although I don't want to open-source it yet, I would certainly open-source it before walking away from it. Speaking personally, it's fun to work on hobby projects and have full control of them, and if I open-source them, it feels like I would lose that.

Heaven forbids it, but if something happens to you ("bus-factor" is called so for a reason), you can't open-source it anymore. Is there at least a second person holding the sources, Loru perhaps?

 

[boogabooga]

Heaven forbids it, but if something happens to you ("bus-factor" is called so for a reason), you can't open-source it anymore. Is there at least a second person holding the sources, Loru perhaps?

That's quite the buzzkill

 

[Urwumpe]

Heaven forbids it, but if something happens to you ("bus-factor" is called so for a reason), you can't open-source it anymore. Is there at least a second person holding the sources, Loru perhaps?

Here its called "struck by lightning". :lol:

 

[Face]

That's quite the buzzkill

Come on folks, we've had the discussion multiple times on open vs. closed frameworks that most of the addons depend on, and there is plenty of evidence now. What did you expect?

 

[jedidia]

The propper orbiter terminology should of course be "swallowed by a black hole"... :lol:

Thanks a lot for that DBeachy, that is one essential library to scratch off.
Just in case you are contemplating coming up with a UMMU replacement, I'd be on board to help. I'll need it something like a year down the road myself.

 

[Urwumpe]

I'll give XRSound a spin later for a small test. But yes, before making it an essential part of an add-on, I would prefer it to be open-source as well.

(But thats nothing a good makefile and some preprocessor code can't solve)

 

[Face]

I'll give XRSound a spin later for a small test. But yes, before making it an essential part of an add-on, I would prefer it to be open-source as well.

(But thats nothing a good makefile and some preprocessor code can't solve)

What worries me a bit is this part of the license:(emphasis mine)

You may not charge a fee of any kind to use this software, nor may you use this software for any commercial purpose or run this software in a public exhibit or public simulator, regardless of the terms governing the Orbiter instance on which it is running, without express written permission signed by the author and sent via hardcopy letter or fax; i.e., an email is not sufficient to grant permission.

If I understand that right, you are not allowed to run Orbiter with XRSound as sound platform in e.g. an educational public simulator or even as a kiosk on a science fair without getting a formal permission. Is that due to the voice actress being involved in the call-outs?