I am writing a midi palyer in C ++ and the part that is obscure is the management of the tracks in order to be able to play them: is someone able to share his knowledge?
Thanks
Thanks
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
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:
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.
I did the parsing of the midi file and I filled an array that contains all the events, notes on / off etc ..
example:
|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|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.
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
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
this should be the solution according to your indications
# 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
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
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'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
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
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.
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.
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
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
There are no replies made for this post yet.
