XMI File Support

[psi29a]

We have two choices here:

• Use Chris's beta patch and work on that until it works
• Use a C version of Thirdeye's implimentation

Either way, we should validate against Thirdeye's music reproduction.

[sezero]

On 1/3/15, chrisisonwildcode notifications@github.com wrote:

I should also add that 0.3 had the same bug

Do you have a (minimal) patch for 0.3 ?

[psi29a]

OK... listening to the 1.fseq in its entirety. The track says it is 2m 36s long, but around 2m the song ends and it is just silence for 36s. Is that normal? This doesn't happen in master.

[psi29a]

[Approx 1m 59s Total] [ ] [100] [ 1m 59s Processed] [100%] <-- that is the length of the track as I hear it on master. (like noted above)

[chrisisonwildcode]

I will look into this, trying to work out how changed to gauss made it into my branch and not master, specially since I didn't touch it ...

[chrisisonwildcode]

Try now :)

[psi29a]

Not noticing a difference, still has 37s of silence difference then how it is in master.

What is exactly is the difference between how Ryan and I implemented XMI support and how you did?

I wish I could look deeper, but I have 3 children that need me. ;)

I'll have more time once they are back at school.

[chrisisonwildcode]

devtest and a hexdump on 1.FSEQ.xmi show a lot of events after the last note off. If I added up all the intervals and did the math I bet its about 37sec worth ... want me to add skipping silence at the end to the -s command line .... ?

On a sort of related note I need to add controller names to devtest output and maybe a time thingy too.

[psi29a]

OK, I just got to listen to them via my headphones at work. There is a big difference in how the files sound between master and updates-branch, which has nothing to do with conversions as the master branch defaults to -g0 (default: no conversion).

Here is the dump of Eye of the Beholder 3, including adlib, pc-speaker and mt-32 versions of the same xmi files.

For example, take Originals/mt-32/LICH 00001.xmi and play back with master branch build, the notes hit hard and drop softly off. It also runs for about 21s. On the wildcode-updates branch, the note holds then lets go, no fadding. It also runs for 31s.

Similar is DARK 00001.xmi, master branch has the notes fadding in (like an intro scene) and lasts about 25s (though sounds cut off at the end), but the wildcode-updates is just full on blast of each note.

If you want, I can dump to wave... but you can do it as well. I consider how it sounds in the master branch to be superior and would consider that the default sound we are aiming for.

[psi29a]

https://dl.dropboxusercontent.com/u/396161/EYE3.tar.bz2 ^-- EYE3 dumps

[chrisisonwildcode]

I am looking into issues mentioned here.

Problem: Master has shorter playing times than Devtest. Answer: Master still contains a bug that skipped some "samples till next" making the overall playing time faster. Devtest shows that -updates has the same time for the XMI playback, the "m" midi, and the -x converter

[chrisisonwildcode]

Problem: LICH 00001.xmi not fading in Answer: When I re-wrote the volume code I thing a part of my brain went on holiday. Code did not match how it was meant to work. Fixed now.

I am still working on trying to figure out why the master instruments decay better ...

[chrisisonwildcode]

ok, I think something got lost when part of the code was re-written/optimised/etc ...

Anyways please test -updates now ...

[psi29a]

OK, I'll give it a look/ear when I get the chance. :)

[psi29a]

I had a listen: LICH 00001.xmi

It still doesn't sound right... same notes are being played at the right time. But the decay or fading out isn't happening.

My original xmi2midi does a dump of: 2576 bytes. Current master does a dump of: 2601 bytes

https://dl.dropboxusercontent.com/u/396161/LICH_old_master.mid https://dl.dropboxusercontent.com/u/396161/LICH_new_master.mid

Now I played the old_master.mid back on the new_master branch wildmidi binary... and it doesn't do any fading/decaying. Weird, so I played back the new_master.mid with the old_master wildmidi and it plays just fine.

It looks like it has nothing to do with the XMI conversion, but how the midi files are being played back.

Is this possibly related to this ticket https://github.com/Mindwerks/wildmidi/issues/84 ?

[psi29a]

Otherwise, I consider this issue closed and that we fix #84 before releasing 0.4.0. What do you think?

[sezero]

On 2/5/15, Bret Curtis notifications@github.com wrote: [...]

It looks like it has nothing to do with the XMI conversion, but how the midi files are being played back.

I believe the generated midi also sounds fine with current 0.3.8?? Current master sounds worse than 'old master' or wildmidi-0.3 and there are issues of extra silence added to start at playback too..

[psi29a]

I agree, three issues here... not XMI related.

1) extra silence added to start of playback 2) extra silence added to end of playback 3) sounds "worse" than than wildmidi-0.3 branch

[chrisisonwildcode]

While I will check again for anything being added accidentally that's adding silence I will point out that a lot of the xmi's I have tested that play with extra silence at the end have the extra silence within them after the last note off.

What I can do if you would like it is modify the command line that skips starting silence to remove silence from either end of the song. Thoughts?

Sent from my iPhone

On 5 Feb 2015, at 8:40 pm, Bret Curtis notifications@github.com wrote:

I agree, three issues here... not XMI related.

1) extra silence added to start of playback 2) extra silence added to end of playback 3) sounds "worse" than than wildmidi-0.3 branch

— Reply to this email directly or view it on GitHub.

[psi29a]

That would give us something to work with in 1) and 2).

How about the 3) case? The decay/fade issue?

[chrisisonwildcode]

I'll have to do some extreme debugging to work out what's going on. It's either a bug in earlier versions, or something got mucked up somewhere.

Or it could be I fixed it but didn't commit because I was still testing then forgot about it in the push to get the formats done.

Either way I will pin down what's going on then let you guys know.

Sent from my iPhone

On 6 Feb 2015, at 9:02 am, Bret Curtis notifications@github.com wrote:

That would give us something to work with in 1) and 2).

How about the 3) case? The decay/fade issue?

— Reply to this email directly or view it on GitHub.

[chrisisonwildcode]

Please test out the Find_Out_Whats_Up_With_Sample_Release branch and it this is no longer an issue please close this and merge the branch.

Just so you know what I did to fix it:

Testing was done by displaying output of the resampler of both the 0.3.8 branch and the 0.4 master branch. This output was then compared and it was noted that 0.3.8 was using sustained release for samples with the sustain flag set while 0.4 branch was not. This has since been fixed in the 0.4 branch.

Once this one is tested and closed I will be doing the fix for too much silence at beginning and end. I wish to reassure you that this is not WildMidi's fault, instead the files do contain the silence. However I will modify the option to jump ahead of beginning silence to remove beginning and end silence from the playback.

[sezero]

The new branch sounds like wildmidi-0.3 branch, so no longer sounding worse and that's good. As for the midi I tested, wildmidi-0.3 reports that it's 2m 56s Total, whereas 0.4/new branch reports 3m 3s Total: possibly some extra silence added?? (sent the midi file to your personal email.)

[psi29a]

Great job @chrisisonwildcode, everything XMI related sounds good.

The extra silence we'll tackle later in another issue, since as you said, you're just following instructions.

[sezero]

Cherry-picked the single commit in the branch into master, and then deleted the branch.