I've checked the latest numbers against the original (supposed) midi file data, and they agree.

Where did the original midi file come from? Did that play back correctly on another piece of software?

We need to go back to the original file that DID play back correctly on something.

Geoff

sorry but what I'm using is a small midi file with random notes that I use for my tests

That's perfectly reasonable. Can you attach that as a midi file (you may need to ZIP it and attqch the zip). I assume that you have played this midi file, and it plays correctly on other software.

Geoff

I think I discovered the problem. When I reorder in a temporal way, my algorithm mixes the events and the original order is not maintained.
For example, if I have two events at the time 1000 and the first one must be played first, my algorithm reverses them and the result is random music.

I added the midi file

Eh?

At timing 1000, there are 3 Note Off commands.

I don't see that what oreder these are implemented will make any difference to the 'sound' of the overall piece, and should not affect the timing of any subsequent notes.
The same thing would apply to any other events happening at the same time, it should not matter which way around they are.

If it DOES make a difference, then there's something else seriously wrong?

Geoff

Aha!

I've not played the file yet, but i've listed it out as text.

I immed noted that the timings in the file I displayed are nothing like the timings we've been using during this thread.

Then, I realised that maybe they ARE, except the numbers you've been giving during the thread are in HEX, but the numbers I had on the screen have been converted to DECIMAL. Looking through, this seems to be the case.

So we've been adding HEX numbers as DECIMAL, which might work to some extent, but it will certainly mess up the music, and will certainly mess up the relationship between the tracks.

For example, at point 1000 (hex) when you've had 900 + 100 and gone to 1000 this should actually go to A00, going to 1000 is like adding 700 not 100!

And have you allowed for the numbers being 7 bit, not 8 bit, apart from the last byte? Most of the values are small enough that you'll get by, but certainly the delta times that are 600 (track 4) will need adjusting as per the variablt length number processes.

Geoff

sorry but only when viewing the data I use the hexadecimal for convenience, when calculating and playing the midi file instead, I work in decimal

in your C program, how do you use delta time?
The problem could be right here. When I play events I do this:

Sleep (deltatime * msppqn);

where msppqn taken from the chunk of the time FF 51 03 t1 t2 t3 holds:
msppqn = (t1 << 16) | (t2 << 8) | (t3 << 0);
msppqn = (msppqn / 1000) / ppqn; // ms

Are you doing this too?

If the delta time for certain events is reversed, there are problems.

This may not be relevant. The adding of the numbers is certainly causing a problem.

In the actual midi file, as converted to TXT, the 4 tracks end almost together. Track 3 ends at point 2560 decimal, which would be 1000 hex, The other three tracks end at 2944 decimal, which would be 1024 hex. The data we've been playing with has the 4 tracks end at different points, so the co-ordination between them is clearly out. Track 3 ends first at 1000 decimal, then track 4 at 1180, then track 1 at 1300 and finally track 2 at 1360. Track 3 is least affected by adding the numbers as decimal when they should be hex, track 2 is most affected.

Geoff

For the record, I've just played the midi file in SynthFont.

The file is about 5 seconds long, and sounds like a succession of chords. It does not sound like 'random', it sounds like someone might have played it. Not very 'tuneful', but OK for testing. I'd say it's playing like it ought to, and is pretty much correct.

Anyway, once we've got the present problem resolved, then we could look at the timing setting. SynthFont allows me to save the playback to a .WAV, which I can send you to compare with what your playback sounds like. If the calc you refer to IS wrong, then the file will play back too fast or too slow, that's all

Geoff

It's a strange file - all tracks are the same channel.

SMF:
type: 1
ppqn: 384
tracks: 5
MTrk:
0: ff58 -- Time Signature: 4/4 96 8
0: ff7f -- Sequencer Specific: 00 00 41
0: ff7f -- Sequencer Specific: 00 00 77 0e 00
0: ff51 -- Tempo: 120 bpm
0: ff2f -- End of Track
MTrk:
0: 90 3c 64 -- Note On
512: 80 3c 64 -- Note Off
768: 90 43 64 -- Note On
1280: 80 43 64 -- Note Off
1536: 90 3c 64 -- Note On
1920: 90 47 64 -- Note On
2048: 80 3c 64 -- Note Off
2176: 80 47 64 -- Note Off
2304: 90 47 64 -- Note On
2560: 80 47 64 -- Note Off
2688: 90 40 64 -- Note On
2944: 80 40 64 -- Note Off
2944: ff2f -- End of Track
MTrk:
0: 90 40 64 -- Note On
256: 80 40 64 -- Note Off
384: 90 47 64 -- Note On
640: 80 47 64 -- Note Off
768: 90 48 64 -- Note On
1024: 80 48 64 -- Note Off
1152: 90 4c 64 -- Note On
1408: 80 4c 64 -- Note Off
1536: 90 40 64 -- Note On
1792: 80 40 64 -- Note Off
1920: 90 47 64 -- Note On
2176: 80 47 64 -- Note Off
2304: 90 4c 64 -- Note On
2560: 80 4c 64 -- Note Off
2688: 90 40 64 -- Note On
2944: 80 40 64 -- Note Off
2944: ff2f -- End of Track
MTrk:
0: 90 40 64 -- Note On
256: 80 40 64 -- Note Off
768: 90 3e 64 -- Note On
1024: 80 3e 64 -- Note Off
1536: 90 45 64 -- Note On
1792: 80 45 64 -- Note Off
2304: 90 45 64 -- Note On
2560: 80 45 64 -- Note Off
2560: ff2f -- End of Track
MTrk:
1536: 90 4a 64 -- Note On
1792: 80 4a 64 -- Note Off
2304: 90 4a 64 -- Note On
2560: 80 4a 64 -- Note Off
2688: 90 4a 64 -- Note On
2944: 80 4a 64 -- Note Off
2944: ff2f -- End of Track
Total time: 0:03.83

this is the same midi file but the tracks have been combined with MidiSoft Studio. This file on my C ++ program sounds correctly.
As you can see, MidiSoft Studio resets the delta time of events with delta time equal to the previous one, but it is not clear by what criterion.
It would seem that at equal time, if the delta time is equal it must be set to zero and means that the events must play together.
[code type=markup]
B0 0 176 7 100 0
90 0 144 60 100 0
90 0 144 64 100 0
90 0 144 60 100 0
90 0 144 64 100 0
90 0 144 64 100 0
80 256 128 64 100 256
80 0 128 64 100 256
80 0 128 64 100 256
90 128 144 71 100 384
90 0 144 71 100 384
80 128 128 60 100 512
80 0 128 60 100 512
80 128 128 71 100 640
80 0 128 71 100 640
90 128 144 67 100 768
90 0 144 72 100 768
90 0 144 67 100 768
90 0 144 72 100 768
90 0 144 62 100 768
80 256 128 72 100 1024
80 0 128 72 100 1024
80 0 128 62 100 1024
90 128 144 76 100 1152
90 0 144 76 100 1152
80 128 128 67 100 1280
80 0 128 67 100 1280
80 128 128 76 100 1408
80 0 128 76 100 1408
90 128 144 60 100 1536
90 0 144 64 100 1536
90 0 144 60 100 1536
90 0 144 64 100 1536
90 0 144 69 100 1536
90 0 144 74 100 1536
80 256 128 64 100 1792
80 0 128 64 100 1792
80 0 128 69 100 1792
80 0 128 74 100 1792
90 128 144 71 100 1920
90 0 144 71 100 1920
90 0 144 71 100 1920
90 0 144 71 100 1920
80 128 128 60 100 2048
80 0 128 60 100 2048
80 128 128 71 100 2176
80 0 128 71 100 2176
80 0 128 71 100 2176
80 0 128 71 100 2176
90 128 144 71 100 2304
90 0 144 76 100 2304
90 0 144 71 100 2304
90 0 144 76 100 2304
90 0 144 69 100 2304
90 0 144 74 100 2304
80 256 128 71 100 2560
80 0 128 76 100 2560
80 0 128 71 100 2560
80 0 128 76 100 2560
80 0 128 69 100 2560
80 0 128 74 100 2560
90 128 144 64 100 2688
90 0 144 64 100 2688
90 0 144 64 100 2688
90 0 144 64 100 2688
90 0 144 74 100 2688
80 256 128 64 100 2944
80 0 128 64 100 2944
80 0 128 64 100 2944
80 0 128 64 100 2944
80 0 128 74 100 2944
[/code]

While reading the MIDI file into your event list, convert the delta time to absolute time. After reading the entire file, sort your event list by absolute time and all events will be in the correct position.

Eddie, I'm doing like you say.
1) I read the mid file and while I read it, I calculate the absolute time for each track
2) reorder the events of the various tracks using absolute time

(1)
[code type=markup]
4D 0 77 84 114 0
90 0 144 60 100 0
80 512 128 60 100 512
90 256 144 67 100 768
80 512 128 67 100 1280
90 256 144 60 100 1536
90 384 144 71 100 1920
80 128 128 60 100 2048
80 128 128 71 100 2176
90 128 144 71 100 2304
80 256 128 71 100 2560
90 128 144 64 100 2688
80 256 128 64 100 2944
4D 0 77 84 114 0
90 0 144 64 100 0
80 256 128 64 100 256
90 128 144 71 100 384
80 256 128 71 100 640
90 128 144 72 100 768
80 256 128 72 100 1024
90 128 144 76 100 1152
80 256 128 76 100 1408
90 128 144 64 100 1536
80 256 128 64 100 1792
90 128 144 71 100 1920
80 256 128 71 100 2176
90 128 144 76 100 2304
80 256 128 76 100 2560
90 128 144 64 100 2688
80 256 128 64 100 2944
4D 0 77 84 114 0
90 0 144 64 100 0
80 256 128 64 100 256
90 512 144 62 100 768
80 256 128 62 100 1024
90 512 144 69 100 1536
80 256 128 69 100 1792
90 512 144 69 100 2304
80 256 128 69 100 2560
4D 0 77 84 114 0
90 1536 144 74 100 1536
80 256 128 74 100 1792
90 512 144 74 100 2304
80 256 128 74 100 2560
90 128 144 74 100 2688
80 256 128 74 100 2944
[/code]

(2)
[code type=markup]
90 0 144 60 100 0
90 0 144 64 100 0
90 0 144 64 100 0
80 256 128 64 100 256
80 256 128 64 100 256
90 128 144 71 100 384
80 512 128 60 100 512
80 256 128 71 100 640
90 256 144 67 100 768
90 512 144 62 100 768
90 128 144 72 100 768
80 256 128 62 100 1024
80 256 128 72 100 1024
90 128 144 76 100 1152
80 512 128 67 100 1280
80 256 128 76 100 1408
90 256 144 60 100 1536
90 512 144 69 100 1536
90 128 144 64 100 1536
90 1536 144 74 100 1536
80 256 128 64 100 1792
80 256 128 69 100 1792
80 256 128 74 100 1792
90 384 144 71 100 1920
90 128 144 71 100 1920
80 128 128 60 100 2048
80 128 128 71 100 2176
80 256 128 71 100 2176
90 128 144 76 100 2304
90 128 144 71 100 2304
90 512 144 69 100 2304
90 512 144 74 100 2304
80 256 128 76 100 2560
80 256 128 69 100 2560
80 256 128 71 100 2560
80 256 128 74 100 2560
90 128 144 64 100 2688
90 128 144 64 100 2688
90 128 144 74 100 2688
80 256 128 64 100 2944
80 256 128 64 100 2944
80 256 128 74 100 2944

[/code]

Mark,

So, how is it playing now? Is it sounding 'right'?

If it's still NOT, then there's still something wrong with the mechanics of playback, or ordering the data.

You mentioned before the overall timing calc, if this is wrong, this would not affect the 'sound' of the playback, it would affect only the speed of the playback so it might be too slow or too fast. If it's the wrong speed, AND jumbled, leave the speed aside for now and concentrate on getting the jumbling OK.

Geoff