XRSound Open-Source Development

[dbeachy1]

Hi all! I'm pleased to announce that XRSound 3.0 is now public on GitHub as open source. EDIT 3-Aug-2021: XRSound is now a direct part of the open-source Orbiter repository here: https://github.com/orbitersim/orbiter/tree/main/Sound/XRSound

The only major change so far for version 3.0 is that, for licensing reasons with the irrKlang sound engine that XRSound uses, XRSound must now be linked dynamically, and thus it now requires that the Visual Studio 2019 redistributable files be installed by end users in order to use it. However, this is much less of an issue going forward now that the new open-source Orbiter core will also require the VS 2019 redistributable files, and so users must already have that installed anyway in order to run the new Orbiter. As such, I also switched XRSound.lib's build settings to generate code for dynamic linking ("Multithreaded DLL" for release builds and "Multithreaded Debug DLL" for debug builds) instead of static linking. This means that new vessels that link with the new XRSound.lib to play custom sounds will now need to use dynamic linking instead of static linking. However, note that XRSound.dll version 3.0 will work with existing vessel binaries linked with XRSound 1.x or 2.x. In addition, there are no new features or bugfixes in XRSound 3.0, so there is no need to update from version 2.0 unless you want to play around with the open-source 3.0 version or use the upcoming 64-bit version.

Regarding 64-bit support for XRSound 3.0, I added 64-bit build targets and have the code compiling cleanly in 64-bit mode. However, I have not tested it with 64-bit Orbiter yet because I still need to get Orbiter x64 to run on its own on my local machine. I'll dig into that more this coming week, but the new 32-bit XRSound 3.0 build is working fine in my testing so far. I will be updating my Web site with the open-source announcement this coming week.

One last thing to note: as a result of cleaning up some VS 2019 warnings in the XRSound codebase, there is one breaking compile-time change in XRSound 3.0 vs. 2.0 when you recompile your existing vessel with the 3.0 XRSound.lib, which is that the PlaybackType enum is now a class instead of an unscoped enum; e.g., XRSound:: PlaybackType::InternalOnly instead of 2.0's XRSound::InternalOnly. However, that is easy to update in your vessel's source code with search-and-replace, and there are no other breaking 3.0 changes I'm aware of.
A huge thanks again to Dr. Martin Schweiger for his amazing Orbiter program and for releasing it under the MIT license. Orbiter has a bright future!

Happy Orbiting!

 

[JDat]

Another great news! Thank you very much Doug!

Now we only need XRsound based MFDradio with playlist local and internet radio listening.
Only problem: too much source code to send thru my brains.

 

[Urwumpe]

Only problem: too much source code to send thru my brains.

The usual problem - so much to do and only one brain.

To me, a RadioMFD would only make sense, if it would also interface with the simulation, for example to communicate with other vessels or surface bases.

 

[Mortov Molotov]

Another great news, and thank you for your generosity!

I do have a question; I've read many times here on this forum that there's an interest into developing Orbiter for Linux (or why not macOS), but will the dependency of XRSound to VS2019 not hamper that development?

 

[Xyon]

Another great news! Thank you very much Doug!

Now we only need XRsound based MFDradio with playlist local and internet radio listening.
Only problem: too much source code to send thru my brains.

I made a Radio MFD that did this, but only for Orbiter Radio - wouldn't be too hard to link into XR Sound and allow other Internet Radio stations

 

[Face]

I do have a question; I've read many times here on this forum that there's an interest into developing Orbiter for Linux (or why not macOS), but will the dependency of XRSound to VS2019 not hamper that development?

What do you mean with "dependency to VS2019"? You can compile the sources with other compilers as well (just not out of the repo), the dependency to Windows APIs is what hampers that development. IMHO, as long as there is no real platform-independent Orbiter API, the compiler project suite in the XRSound repo is a minor thing in this regards.

 

[dbeachy1]

Another great news, and thank you for your generosity!

I do have a question; I've read many times here on this forum that there's an interest into developing Orbiter for Linux (or why not macOS), but will the dependency of XRSound to VS2019 not hamper that development?

The biggest dependency is its liberal use CStrings (they are super convenient!), plus a few Win32 API calls on the XRSound.lib side to avoid MSVCRT dependencies. However, the underlying sound engine, irrKlang, supports Linux (and even Mac), and the Linux binaries for irrKlang are freely downloadable (in fact, all three sets of binaries are in the same download package). A Linux version of XRSound would definitely need a separate repo, however, unless there is a Linux library that adds CString support.

 

[dbeachy1]

I have the x64 build of XRSound working now (thanks to Jarmonik for uploading an x64 binary package for the Orbiter core and the D3D9 client so I could test XRSound x64!). ?

EDIT:
Beta binaries of XRSound 3.0 are now available for download on GitHub for both 32-bit and 64-bit Orbiter. I want to do more testing with a proper Orbiter 64-bit installation (i.e., Orbiter x64 installed from a binary package that installs and runs cleanly) before I make XRSound 3.0 the "official" public build for download, and so XRSound 2.0 will be the public release on my Web site for a while yet.

 

[Face]

Beta binaries of XRSound 3.0 are now available for download on GitHub for both 32-bit and 64-bit Orbiter. I want to do more testing with a proper Orbiter 64-bit installation (i.e., Orbiter x64 installed from a binary package that installs and runs cleanly) before I make XRSound 3.0 the "official" public build for download, and so XRSound 2.0 will be the public release on my Web site for a while yet.

Works like a charm in my environment, thanks for the quick work!

I'd love to contribute the sound bridge code, but I'm a bit worried because of its OrbiterSound reverse-engineering origin. I'll ask DanSteph if it would be OK for him if that code goes open.

 

[Thymo]

Great news! Someone already made a draft PR to make NASSP work with XRSound but it was postponed due to the license conflicting with GPL. I'm gonna take another look at it to see if it can be made to work now that it's under MIT.

 

[Face]

Great news! Someone already made a draft PR to make NASSP work with XRSound but it was postponed due to the license conflicting with GPL. I'm gonna take another look at it to see if it can be made to work now that it's under MIT.

Usually pulling MIT code into a GPL code-base should be no problem at all. You just have to make it clear that the code is licensed this way and keep the copyright notice.

 

[martins]

I want to do more testing with a proper Orbiter 64-bit installation (i.e., Orbiter x64 installed from a binary package that installs and runs cleanly) before I make XRSound 3.0 the "official" public build for download, and so XRSound 2.0 will be the public release on my Web site for a while yet.

Regarding binary packages: I wonder if that could be set up to happen automatically with the github CI. I already have a package target set up in CMake (producing both zip and msi), so I guess it should be possible to tell CI to build the package on a successful Orbiter build and to publish it on github (replacing the previous package - this is just intended as a current snapshot). This would help people who want to keep up to date with Orbiter developments but don't want to compile it themselves. Probably the 64-bit version would be enough, and just the zip package.

Maybe one of the github experts around here could comment?

 

[Fabri91]

Regarding binary packages: I wonder if that could be set up to happen automatically with the github CI. I already have a package target set up in CMake (producing both zip and msi), so I guess it should be possible to tell CI to build the package on a successful Orbiter build and to publish it on github (replacing the previous package - this is just intended as a current snapshot). This would help people who want to keep up to date with Orbiter developments but don't want to compile it themselves. Probably the 64-bit version would be enough, and just the zip package.

Maybe one of the github experts around here could comment?

If this is possible I and others would very much appreciate this.

 

[Xyon]

Regarding binary packages: I wonder if that could be set up to happen automatically with the github CI. I already have a package target set up in CMake (producing both zip and msi), so I guess it should be possible to tell CI to build the package on a successful Orbiter build and to publish it on github (replacing the previous package - this is just intended as a current snapshot). This would help people who want to keep up to date with Orbiter developments but don't want to compile it themselves. Probably the 64-bit version would be enough, and just the zip package.

Maybe one of the github experts around here could comment?

You may want to consider how you want to control this, from a milestone release perspective - often this sort of packaging and release is controlled via git tags, which are just shortcuts in the repository that point to a specific revision and mark it out as important. So you can run your CI that you have now on each commit, but when you're ready to cut an actual release you do everything as normal, create a tag in git that points to that commit, and push that to the repo, which kicks things further down the pipeline (assuming the checks at the CI stage pass, naturally). That second step doesn't have to do anything special per se, but just handle the packaging - and github will list tagged builds out on the Releases page by default.

 

[martins]

Could you do both? You'd have your release packages along the way to provide users with the latest stable version, but you would also have the "current" package for developers, built from the latest master commit. Maybe they could even set up their own repositories to look for changes in that package, automatically fetch it and compile their own addon coded against it, to get instant warning of impending trouble.

 

[Thymo]

Usually pulling MIT code into a GPL code-base should be no problem at all. You just have to make it clear that the code is licensed this way and keep the copyright notice.

With MIT this is indeed no problem but with the previous proprietary license it was. In order to use it we had to statically link XRSound's library, That would violate both XRSound's library by redistributing that library and it would violate the GPL as we would not be allowed to distribute binaries of NASSP because we can not supply all the source code. The same issue existed when Orbiter was closed-source (statically linked SDK) and OrbiterSound. With Orbiter open source that is now resolved but we are still technically violating it because of OrbiterSound. I hope to change this soon.

You may want to consider how you want to control this, from a milestone release perspective - often this sort of packaging and release is controlled via git tags, which are just shortcuts in the repository that point to a specific revision and mark it out as important. So you can run your CI that you have now on each commit, but when you're ready to cut an actual release you do everything as normal, create a tag in git that points to that commit, and push that to the repo, which kicks things further down the pipeline (assuming the checks at the CI stage pass, naturally). That second step doesn't have to do anything special per se, but just handle the packaging - and github will list tagged builds out on the Releases page by default.

Right now with NASSP we have a new pre-release for every commit that is pushed to our develop branch. Effectively this means a new release every other day. When NASSP 8 releases (soon hopefully) I plan to organize a new way of providing people with builds. I would recommend against a similar situation for Orbiter.

 

[pushkin]

Thanks for making this open source! Crazy week it has been for orbiter fans. I would love to contribute with this if you guys are interested. I'm not as smart as most of you so I won't be of any help programming and such but I do love sound design so I could do an overhaul of the sound to make it even more immersive. Not that the sounds are bad or anything right now but they can sound a bit flat at times. I made you guys a few a/b examples.

https://soundcloud.com/sea-of-separation%2Fsets%2Forbiter%2Fs-MFRa60NYChH

Let me know if this would be of any interest. I love doing these things and I love Orbiter.

 

[dbeachy1]

I like the beep change, for sure! The others are a bit subjective (e.g., the new scrams sound harsh to me), lol. In any case, I love the idea of having multiple sound packs users could choose from and use -- we could even bundle them all into the main XRSound zip.

 

[Fabri91]

I agree, the new scram sound seems to be very harsh and odd. Otherwise, good work!

 

[jedidia]

I have no idea what a scram engine is supposed to sound like, but the new one makes me think of a couple aliens preparing to launch a new Hans Zimmer soundtrack. While the old one always made my ears bleed, but somehow I figured that's appropriate for a gazillion-horsepower air compressor. Not sure which one I prefer.

I do prefer the voice without reverb, somehow spaceship interiors don't seem like places with much reverb. I do, however, prefer the new API sound, sounds more businesslike, like some machinery is chugging away somewhere deep in the bowels of the ship.

So, mixed opinion from me. But overall, more sounds, always a good thing!