Here's how the music sounds with my EWQL samples, without much setup, so they will sound better once I finetune them (and get more detailed with the instrument definitions):

EWQL_CR01
EWQL_EM11
EWQL_REB01
EWQL_REB11
EWQL_TR22
EWQL_MIX

WOW!
X-Wing has never sounded better than that!

Are you playing them a little bit slower than usual?

You are correct; there can be overlap. Also, it's not the first four beats of silence that are removed. In fact, it only skips 3 beats of silence and leaves the last one. It's not set in stone either: the silence to be skipped is dictated by that SysEX Jump command I keep mentioning.

In DG02's case, in the very first tick, there's a SysEx command 7D 30 00 00 00 00 00 00 00 00 00 00 04 00 00 00 00.

This tells the playback engine to jump ahead to Beat 4, which is the last beat of Bar 1, not Beat 5, which would be the first beat of Bar 2. This is also before that drumroll leadin occurs.

Additionally, in all the inflight tracks there is another SysEx command 7D 40 00 01, about a beat before the track ends. This is the command that tells the engine when to start playing the next segment., and this is why the playback is seamless even though only 3 out of 4 beats of initial silence are skipped by the SysEx jump.

I haven't confirmed this as an absolute fact for every single inflight segment, but it seems it's laid out like this: The first 3 beats (not 4) of silence are cut off. But, at the end of each segment, the next segment is played one beat before the current segment is done playing. This makes it possible for segments to have up to 1 beat of leadin.

It would be dangerous to assume all of them jump to Beat 4 though, I'll check them all out and see. In my playback implementation there is no need to assume this since it can be read from the SysEx command.

Do you think we should just keep the "empty" beats in the WAVs then, to make implementation easier?

Well, not on purpose. You're right though, my files are slower than your files. I guess I might have messed up somewhere. Are the MIDIs all at the same speed?

Yeah. I can make some metadata list that contains the positions of each of the various jump/marker points so that we still get the jump points and stuff like that. (Or to avoid that -- this is quite the kludge -- but run the MIDI engine silently alongside the digital version to let the timing be handled by that.)

Also, I figured out why the inflight tracks have those conditional jumps to second tracks with the two notes: It turns out, this is an alternate earlier "start next song" position, and the second track is there to make the segment stop playing one beat after that point. Now that I realize it, I recall that it's there specifically for event cues so that event cues can "interrupt" as segment halfway through. You might hear this most when shooting down enemies.

So, it's like this: some tracks have an alternate endpoint (denoted by SysEx 7D 30 00 00 01 00 00 00 01 00 00 00 01 00 01 09 00) for event cues if there is one queued, where it stops playing after the next beat instead of playing to the end, otherwise it plays the next segment at the SysEx 7D 40 00 01 location one beat from the end.

If it might help you I can replace this command with a CuePoint command and descriptive text if your DAW supports them, so you can see where the possible alternate break points are. Maybe it might be easier for you if you just ignored them, though. I'll brainstorm some elegant ways to handle this.

No, my MIDIs are the same speed as they are in game.

Here's the link to them. They contain all tempo data.

http://www.mediafire.com/download/o7wmmap85gr4ogw/GMIDI.zip

So do you have anything flyable by a player yet? Any screenshots?
I have spent the last month or so developing a multiplayer x-wing/tie thing in Unity. I have flyable x-wings, a-wings, y-wings, TIE fighters and TIE interceptors so far. I plan to include many more but limit how many are available in any session.
Although I can fire lasers from each, the way I've done it isn't ideal as hits are not always registering. I still have a long way to go...setting weapon modes, linking canons and implementing a shield system etc, but for a novice it's all going ok.
I doubt I could help, as you sound much more competent at it than I am :)

Great! EWQL is a great library for VSTi music. I think you should try and get every midi done and then Tarvis can use those for the IMuse system he is working on. Also, Laser you should look into Spitfire as they have some great orchestral libraries and they use Kontakt too I believe.

It does kind of seem like the EWQL wavs play slightly slower then the midi ones. I'm sure there's an easy fix to that just by speeding up the playback rate. To get as close as possible to the midi version.

It's great that you have been working on your own version of X-Wing in Unity. Maybe post a link so that we can test it out. I don't think Azrapse has actually programmed or made anything yet but rather just planning and I think Tarvis started his own iMuse system already trying to mimic the X-Wing one as well as play wav versions of the ingame music.

Hi. I developed a little prototype several months ago with flyable ships. They were not star wars ships, but models created by my own team for an unrelated indie project.
However, creating an entire game is way more work than focusing on remaking the flight engine of an existing game. We made some bad (at the moment) decisions, like using the Unity physics engine to model a more realistical space combat than the one in X-Wing.

The problem is that more realistic doesn't equal more fun, and also figuring doing something as simple as a homing concussion missile, or two ships docking while one is still moving, as seen in X-Wing, it's way more complex with a realistic physics engine where you need to account for linear and angular momentum and continuously correct the thrust applied in all directions. A headache.

That project is now on hold for other reasons (art assets responsible chickened out). So instead, for this one, I am moving to a simplified physics approach, just like the X-Wing series use and needs.

If you feel curious about what we had back then, this is one of the later builds of the flight engine. There is no story or anything. Just a few flightgroups, fighting in a team deathmatch.
The controls, during the development, were a mix of X-Wing's and Quake, so that someone could test the game by using their hands as they play a FPS.
W: Speed up throttle by 33%.
A: Rotate counterclockwise.
S: Slow down throttle by 33%.
D: Rotate clockwise.
ENTER: Attempt to match speed with target. It tries to keep it matched, unlike in XW series.
T: Select next target.
Y: Select previous target.
You move the ship with the mouse like in X-Wing and TIE Fighter DOS versions.

The game has several navigation aids that will not be used in this remake. You will identify them easily.
You will also identify some placeholder sounds taken from XvT.

In any case, I'm writing the flight engine for this XW project from scratch. It can already read the .XWI mission files so that I can test the engine with real life missions from the X-Wing installation folder or its CD. It has basic definitions for the different craft types, and programs all ships with their objectives, orders and other data.

It is not that I have been just planning. However I am approaching the development of the flight engine from a different direction than what I did with Ships On Fire. Instead of having something flyable as soon as possible, I am going for writing the code that takes care of simulating the mission and the AI of the different flight groups.

The reasons are two:
- Flying a ship requires the cockpit art and instrument panel definition work done. I don't want to program something to later scrap it with another thing, so I will program the player craft last.
- X-Wing missions are more than deathmatches. They have many events and triggers that rely on everyone following their choreography to the letter. I need to have the AI fly around in the same way as it does in X-Wing, otherwise the missions' balance will be broken.

So what I am doing currently is a mission flight engine where the player can only look around with a free camera and see how the different flightgroups carry out their designated orders.
It's basically the same as what you could see if you pressed Shift+M in XvT. You would go to the Map screen and your ship would be taken over by the AI. And you could see the battle going on without you.

I am using the XWAU models as placeholders. I repeat, they are placeholders until we find something else (or we get their permission to use them).
These are some screenshots:

Adding to that I found at least one instance, where 3 of the "empty" bars at the beginning of the clip are supposed to overlap the currently playing clip: DG-S

The notes in that clip start at beat 5, BUT there are some tempo change events starting at beat 2, so when they are overlapping the currently playing clip, it will gradually slow down from the standard 137.8 bpm to DG-S' 133 bpm. This, of course, is something that really only works with MIDI, because no matter which clip is currently playing (at the standard 137.8 bpm), it will gradually slow down. To replicate this with digital audio, we would have to record that slowdown for each and every music clip that could lead to the DG-S transition.

For the time being I'd like to propose a simplification regarding the digital audio: Let's just keep ALL the clips at a fixed speed of 137.8 bpm. Speed changes are just too damn difficult to pull off here. Also we'll keep 4 beats of lead-in (deleting the notes in the first 3 beats, so we're not losing stuff like the timpani roll-in) and 3 beats of reverb trail.

On my end that the tempo slowdown events are on beat 3. But, the SysEx jump tells it to jump to Beat 4 which would evidently skip them. I honestly can't tell if it's slowed down in the game or not. I'll try capturing some MIDI output from DOSBOX and see when the tempo change events occur. I suspect that because of the jump only the final tempo change (setting it to 133BPM) occurs, but I could be wrong.

I'm fine with that. 138 to 133 is pretty subtle. In fact, if you made SU 133 while DG-S is left at 137 I doubt anybody would notice. The only event that causes DG-S is hypering out of a victorious mission, in which case the hyperspace sounds would mostly obscure it anyway.

------------------------------------------

Anyway, some updates on my iMUSE simulator: it might take longer than a week to finish, because this is actually the first code I've ever written that involves MIDI so I have a bit of research to do.

So far I think I've settled on using .NET or Java so I don't have to waste time coding or finding UI library that will just be left unused in the actual game engine. The actual music engine code pretty much does nothing more than send arrays of bytes to the MIDI output, so it shouldn't be too hard to port to whatever language the engine uses. The UI for this is for nothing more than triggering music transitions and such.

I'll use PortMIDI as the library that handles sending this MIDI data to the actual MIDI devices on the system. It supports Linux and Mac as well. The most commonly used library for this is SDL_mixer, but it is notorious for not fixing various bugs involving volume and WIndows Vista and up. PortMIDI has since been adopted by several Doom sourceports because of that so I think it's up to the task. (It has a Java verison too if I want to go that route)

Otherwise, handling the MIDI data itself is straightforward: just send the MIDI events from the file to the output stream verbatim, unless it's one of those special iMUSE SysEx messages I mentioned. In the case of those events, handle things like switching to a different MIDI file or different track.

I can't seem to find the LFD specs anywhere (even though it's clearly figured out due to the various browsers out there) so also for now it'll have to work with the extracted GMID files.

First I will implement the logic that dictates the track order (playing them dynamically).
Then I will implement the Jump command to skip to the right parts (remove gaps and make seamless).
Then once that's finished, I'll add MUST/Adlib emulator/FluidSynth output options.

Then, finally, I'll think of the best way to implement digital recorded music. I think the best way would be to run the MIDI engine with no sound output, but instead of playing MIDI songs at the cue times it will play the corresponding ogg instead. I will just have to come up with a way to convert from Beat+Tick MIDI time format into an actual timestamp to skip to in the ogg, that accounts for things like tempo changes. If I can do that, then we won't need any extra metadata after all!

I would write a convenient c# class for you to use, but it will have to wait. Meanwhile here is the spec.

Oh wow. That's super simple. Don't bother writing it for me!

Would it be possible for "XWVM" to support soundfonts on its own? ScummVM allows usage of soundfonts via its FluidSynth implementation, so it would be a nice feature for this as well.

It could, but if the user has soundfonts set up as a MIDI device already, why not just use that instead? It would save having to locate them and configure it all over again