Hello,

You don't tell us very much, what point you're at already, etc.

What's do you mean be 'obscure'? Maybe the 'management of the tracks' is not mentioned because it's pretty much up to you how you do that? The tracks aren't very important regarding the PLAYING of the data, although if you want to edit/save the data then it might be useful to keep the tracks in memory.

Either way, the important thing is that you need to load all the data into memory (there are alternatives, but I'll not get too complicated) and then sort everything (regardless of track) into time order. This could be done by re-arranging the midi elements, or by creating an index where the indiv items point to the location of each element where-ever it is, and the index is then sorted into time order.

You need to keep the track data there, as your playing might wish to be selective, i.e. certain tracks are ON and others are OFF (not played).

I'm sure there are examples of this on the web, in various languages. I've mainly used C (as opposed to C++) although I've been told that I write C in a C++ way. The main program I wrote to play midi files was needed to do other things as well, so this stores the midi data in my own file system, but I had specific purposes for doing that over and above merely playing the data.

Please make any follow-up questions much more specific than your original. Then I can give more specific answers.

Geoff

Thanks for the reply.
I did the parsing of the midi file and I filled an array that contains all the events, notes on / off etc ..
example:
[code type=markup] |4D|54|72|6B
00 |90|3C|64
200 |80|3C|64
100 |90|43|64
200 |80|43|64
100 |90|3C|64
180 |90|47|64
80 |80|3C|64
80 |80|47|64
80 |90|47|64
100 |80|47|64
80 |90|40|64
100 |80|40|64
00 |FF|2F|00|
|4D|54|72|6B
00 |90|40|64
100 |80|40|64
80 |90|47|64
100 |80|47|64
80 |90|48|64
100 |80|48|64
80 |90|4C|64
100 |80|4C|64
80 |90|40|64
100 |80|40|64
80 |90|47|64
100 |80|47|64
80 |90|4C|64
100 |80|4C|64
80 |90|40|64
100 |80|40|64
00 |FF|2F|00|
|4D|54|72|6B
00 |90|40|64
100 |80|40|64
200 |90|3E|64
100 |80|3E|64
200 |90|45|64
100 |80|45|64
200 |90|45|64
100 |80|45|64
00 |FF|2F|00|
|4D|54|72|6B
600 |90|4A|64
100 |80|4A|64
200 |90|4A|64
100 |80|4A|64
80 |90|4A|64
100 |80|4A|64
00 |FF|2F|00|[/code]

If I try to play the events as they are in the array, the events / instruments play in sequence, not together where it is foreseen in the song. to understand: first all the drums, then the guitar and finally the piano.
I also tried to reorder them for delta-time but random sounds are generated.

Sure there is an intelligent way of rearranging the events in the various tracks but I don't know it.

There are many MIDI players on GitHub. Look and see how others do it and choose the method you like best.

thanks for the link Eddie, I have already seen many c / c ++ source codes but it is not always trivial to obtain the information I need simply by reading the source code

Mark,

The data that you show is clearly for a Type 1 midi file, with multiple tracks, so for this you need to accumulate the times and work with the accumulated numbers, and order the mixed data by this number. When you're dealing with a type 0 file, then you could work with the data as it is, and act upon the indiv delays between items/commands, but I'd expect that most people would still accumulate the delta time for clarity as you'll still need to compare the data time with the computer clock time and it's easier to run both from 0 and accumulating.

If accumlating, then the indiv delta times that were, say, 80, 80, 100, 100 would become 80, 160, 260, 360 and if the timings for Track 2 were 80, 100, 80, 100 then this would become 80, 180, 260, 360. The two tracks merged would then then be 80 (1), 80 (2), 160 (1), 180 (2), 260 (1), 260 (2), 360 (1), 360(2) .

Geoff

Geoff,
is this what i have to do?

Yes, that looks more likely.

When you're playing, work down that table, a line at a time, and for each line, do each column (track) in turn. Wait for time due as required.

Geoff

this should be the solution according to your indications

[code type=markup]
# DT EV NT VEL SUM
t1 0 90 3C 64 0
t2 0 90 40 64 0
t3 0 90 40 64 0
t2 100 80 40 64 100
t3 100 80 40 64 100
t2 80 90 47 64 180
t1 200 80 3C 64 200
t2 100 80 47 64 280
t1 100 90 43 64 300
t3 200 90 3E 64 300
t2 80 90 48 64 360
t3 100 80 3E 64 400
t2 100 80 48 64 460
t1 200 80 43 64 500
t2 80 90 4C 64 540
t1 100 90 3C 64 600
t3 200 90 45 64 600
t4 600 90 4A 64 600
t2 100 80 4C 64 640
t3 100 80 45 64 700
t4 100 80 4A 64 700
t2 80 90 40 64 720
t1 180 90 47 64 780
t2 100 80 40 64 820
t1 80 80 3C 64 860
t2 80 90 47 64 900
t3 200 90 45 64 900
t4 200 90 4A 64 900
t1 80 80 47 64 940
t2 100 80 47 64 1000
t3 100 80 45 64 1000
t4 100 80 4A 64 1000
t1 80 90 47 64 1020
t2 80 90 4C 64 1080
t4 80 90 4A 64 1080
t1 100 80 47 64 1120
t2 100 80 4C 64 1180
t4 100 80 4A 64 1180
t1 80 90 40 64 1200
t2 80 90 40 64 1260
t1 100 80 40 64 1300
t2 100 80 40 64 1360
[/code]

What??

Might be right, insofar as I can make sense of it. I assume the list you show has items from different tracks? I'm assuming that the total accum ### is correct, and allowing for assumed different tracks then yes it seems to make sense. It would have been a help if you'd included a track #.

Yes, I know, I could read the last table in conjunction with one of the earlier ones, but my ancient brain needs a little help!!

Main thing. Does it SOUND better now??

Geoff

I added information to my last table

And......

Does it sound better now?

Geoff

unfortunately it does not sound correctly

Oh, right.

There must be something wrong with the data then.

I'll work through it, and see if I can spot anything.

Geoff

I've checked through the numbers, and they seem to be correct.

Maybe the midi data is not correct for the music (or score) that you're trying to represent? I've got no way to check that.

Do you have a 'score'?

Geoff