Hi. Thanks for testing.
I feel quite puzzled because I am encountering some glitchy sound with the music in both of my computers (a 64-bit Windows 7 Ultimate, with quad i7, 8GB RAM; and a little 32-bit Windows 8.1, dual Atom with 4GB RAM).

I don't really know what it is. But I am not really a sound engineer or audio specialized programmer so even when I have tried with some doublebuffering, single buffering, load everything ahead of time into RAM (that is why it is taking 300MB of RAM, as all the samples are loaded uncompressed), it seems not to make any difference.
I am just buffering chunks of data to the soundcard at the rate it needs (1024 stereo samples every 25 ms (44kHz)) and most of the time it sounds flawless, but some times I can hear a chirp or a crack here and there.

Well. The proof of concept is there, it seems it works, so Tarvis' and your work has at least seen some use already. :)
I think I will focus on the AI again and leave the music part for later of for someone else that is more knowledgeable than me about that subject. I will soon upload the whole source to Github once the AI actually does something that can be shown.

Next time, I will have the music tracks compressed (MP3 or ogg) so that the game is a smaller download, as currently basically 90% of the game size is the iMuse WAVs. It will be a Windows 32bit Exe download, not a web player.
For some reason, the models don't want to show on the webplayer. I wonder if it is because of their format (they are .3DS models) or what.
It doesn't bother me much, as they are temporary anyway. They are exported from the .OPTs from the XWAU project and I don't think they will ever allow us to do that.

I have been experimenting with having a 3D cockpit. I have no cockpit model done at all, but I have been testing with the 3D UI and it looks quite promising. We can lay interactable buttons, labels, sliders and panels in a total 3D environment around the camera, quite easily.
Better even, it will allow for fast prototyping of the cockpits, by reading the position, orientation and type of "instruments" from some text file, so we will not have to hardcode them. The 3D UI elements will be place on top of the cockpit 3D model like if they would be decals.
Those with a touch screen will be able to interact with the instruments directly without keyboard shortcuts, thanks to this 3D UI. So for example, you could slide the Laser power manager up with your finger, or slide the shield frontwards, backwards, or center them, etc.
Maybe this allows for better immersion with an Oculus? I don't know.
Also, it will allow for localization of the labels, like "Throttle", "SPD" (speed), "ELS", "Eject", "F/R" (front, rear), etc.

I have a couple of questions:
- Do you know a fast way to compress the wavs you provided to ogg or mp3 in an automated way, instead of me having to do each one at a time? Any free tool for it?
- Do you know the purpose of the TRAN.WAV track? It's pretty long, and it contains a weird long sound that reminds me to the sound that used to be played in the cinema when the THX logo appeared. But this is way longer than that and I cannot remember being used in the game.

foobar2000 is stellar at batch-converting audio (you can even use it to render MIDI). Some of the best software ever made, if you ask me. You'd need to ignore potential patent niggles to convert to MP3, but Vorbis should be no problem.

I have no artefacts listening to the music here, by the way.

Thanks!
I batch converted everything to ogg. The music takes now ten times less space, decreasing the demo program download size from 97 MB to 17 MB. Also, I have totally revamped how I stream the music fragments and now all traces of audio artifacts and clicking have disappeared.
Funny enough, the code is now even simpler than before. I feel stupid for not having thought on this evident solution the first time. Before, I was buffering the raw audio data from the different music fragments, queueing each at it's own intended offset, and combining them by adding the concurrent samples together, before passing the resulting data to the audio hardware.

Now, instead, I just replaced the whole sh*t with 3 AudioSources, each of them playing their own musical fragment, just scheduled to start playing at a particular "offsetted" DSP time so that the iMuse chaining sounds seamless. And it works wonderfully! It supports compressed audio, the code is like 10 times simpler, it uses 10 times less RAM, and all audio processing is done at hardware level, so there is no chirping or clicking, and CPU load peaks doesn't seem to affect the playback noticeably. Before, the music would stall at uncomfortable pitches whenever I would ALT+TAB or otherwise cause any high CPU peak. Now, I can even minimize the program and compile another build and the music will keep on playing from the background without any problem.

So for now, and until we come back and revisit it for the concourse, I consider the iMuse system finished and will focus back on the AI and mission simulation.

Oh man, I've been gone too long, looks like you already pulled it off before me!

Nice work, I must say! About the transition to the Deathstar track, I'm sure we could use some of the existing pieces to make transitions to/from it that sound good. Currently there just weren't any defined because there was no case where it even would transition in the original game. I'll play around and see what sounds good. To and from the Dogfight state would be the most important. Is there a download version to easily mess around with it or is the music table all hardcoded right now?

I like the idea of using Deathstar track for capship battles, best criteria for playing it would be if turbolasers are targeting you. Because X-Wing could really use a bit more music variety compared to TIE Fighter. Hell, personally I'd look into using the Training track somewhere in the main game too.

I had an idea, since Fail being used for shields down is a bit odd, what if it was used for a different context, such as being chased by an enemy craft? The inverse of the Chase state, if you will. I'll look into TIE Fighter's states, since it has a few more, maybe they can be applied to X-Wing as well

Also, I think using the Capship Destroyed cues sound just fine, even though the original game didn't actually use them properly.

Nice to see you back!
And sorry for stepping on your work, but I was so fed up with the AI routines (much to program, little to see), that I wanted to have something more fun done.

I think the Fail theme totally belongs to the Fail mission event. In my opinion, they made Michael Land write it for that purpose, then they found out they couldn't, for some reason, trigger the fail mission event (not even as a message!), and they just recycled the Fail theme into that shields down nonsense.
Not even TIE Figher has a shield down theme. So I would say we just put back there the Fail Event that was meant to exist and that X-Wing has always needed, and we use the Fail music for it.

It would be nice to have a Chased theme, though. But the Fail theme sounds too dramatic for something that will be sounding that often.
The training theme, on the opposite side, sounds a little bit too cheerful. So I was thinking we could use it mainly for those minefield missions, or when you are nearby a minefield. Or what do you think?

I like the idea of its use around minefields (if there are no enemy fighters nearby). Mine-shooting has always been a pretty cheerful thing. ;)

I'm making a desktop version with moddable iMuse tables. They will reside in your %AppData%/XWVM folder, in a JSON file.
You can always delete it to get it rebuilt with the default tables upon next run.

Would it be possible to have the MIDI version of the music included as well?

Also, I have already re-worked the in-flight music a bit. I can upload it as OGGs.

I already recoded it as OGG myself . But if you have changed something else, sure! Did you detect any problems in the current tracks?
I was not planning to add support for the MIDI music in the Unity remake. Somehow, I have always seen this as a prototype to check whether we can indeed create a deign remake, have most missions working, etc, then maybe change the 3D engine to something else as Tarvis suggested. Because most of the work (AI, music, menus, flight physics) is platform-independent.
Of course we can stick to Unity, as it is where I feel most confortable at, anyway.
I think there is a nice free asset to make MIDIs playable from Unity without much problems, so I will need to research that.
Just tell me where you uploaded the new reworked music and I will integrate it with the new build.

No, there weren't any problems... I just improved the mix and EQ of the tracks a bit. I sent you a link via PM :)

Okay. I will try to have it ready later today. I will need to do something with the placeholder XWAU ship models first because, for some reason, they are taking a crazy amount of space, and there are just 16 of them, but the final build is towering to more than 100MBs for a prototype at this early state...
It doesn't matter, as the AI is not doing anything to write home about, so if the ships don't appear in this build, it's not a big loss.

You got the link to the windows standalone, with the new tracks, and moddable iMuse tables, as PMs. If any other is interested on downloading it, just PM me.
The reason not to post it here is to comply with the XWAU models terms of use.

While testing the table file, I have tried to use a transition fragment for the DeathStar theme to make it link better with others. Actually, all the DS1x fragments sound quite okay as a transition from any other theme, except for "Event" that I left as it was.
And if I am not mistaken, isn't the TR-T fragment unused in the table? Maybe we could use it as a transition between Training and the others.

Stupid me, I forgot to tell the point of all of this. :D
The main reason of this build is, other than to try out Laserschwert new tracks, is to allow you to experiment with the iMuse tables.
The main difference is that the game, upon first run, will create a file named imusegraph.json at your %AppData%/XWVM folder.

That file will contain the iMuse tables just like Tarvis described them, in JSON format. I recommend you to pass the contents of the file thru a JSON prettifier like this one, because the default output is quite compact-ugly. You can edit it to alter the fragments, transitions and whole themes played.

The structure of the file is an JSON object with this format
{
"themes":{
"ThemeName1":{
"nodes": {
"nodeName1":{"fragment":"fragmentToPlay", "next":["nextNodeAlternative1", "nextNodeAlternative2",...]},
"nodeName2":{"fragment":"fragmentToPlay", "next":["nextNodeAlternative1", "nextNodeAlternative2",...]},
},
"transitions":{
"ThemeName1": ["nextNodeAlternative1", "nextNodeAlternative2", ...],
"ThemeName2": ["nextNodeAlternative1", "nextNodeAlternative2", ...],
...
}
},
"ThemeName2":{
"nodes": {
...
},
"transitions":{
...
}
},
...
},
"events":{
"EventTypeName1":[
"MusicFragmentAlternative1",
"MusicFragmentAlternative2",
...
],
"EventTypeName2":[
"MusicFragmentAlternative1",
"MusicFragmentAlternative2",
...
],
...
}
}

Thanks! Most merit go to Tarvis and Laserschwert. Tarvis found out the mechanics and the tables, Laserschwert turned the old Midis into wonderful tracks. I only pieced those two things together, so far. :)
I answered your PM.