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.
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.
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) .
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!!
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 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?