fbpx
Skip to main content

MIDI Forum

Notifications
Clear all

player midi c++

45 Posts
4 Users
0 Reactions
14 K Views
Mark
 Mark
Posts: 27
Eminent Member
Topic starter
 

I'm working on it

 
Posted : 04/05/2020 8:52 am
Mark
 Mark
Posts: 27
Eminent Member
Topic starter
 

the reordering of events according to a temporal order is correct, now I have discovered that the new deltatime must also be recalculated for each event: but how?
[code type=markup]
type 0 type 1
4D 77 84 114 0 0 4D 77 84 114 0 0
90-C4 144 60 100 0 0 90-C4 144 60 100 512 0
90-E4 144 64 100 0 0 90-E4 144 64 100 256 0
90-E4 144 64 100 256 256 90-E4 144 64 100 256 0
80-E4 128 64 100 0 256 80-E4 128 64 100 128 256
80-E4 128 64 100 128 384 80-E4 128 64 100 512 256
90-B4 144 71 100 128 512 90-B4 144 71 100 256 384
80-C4 128 60 100 128 640 80-C4 128 60 100 256 512
80-B4 128 71 100 128 768 80-B4 128 71 100 128 640
[/code]

 
Posted : 05/05/2020 9:22 am
Geoff
Posts: 1039
Noble Member
 

Hello,

Not sure what you're referring to here.

Assuming the two files are the same music, then the accumulated delta times for each event should be the same for a type 0 and a type 1 midi files. If they're not, then the playback of the two versions will be different.

Secondly, if the file has not been changed, there should be no change to the delta time, and doing so might change the music again. The playback will be controlled by the version of the delta time in the data, and the calculated delta time managed by the program. At each point, the event will be actioned when the two match. If, for example, there is a tempo change within the data, then the calculation of the delta time within the prog will alter, but the delta time within the data will not, so the playback will speed up or slow down to keep the two in line.

Geoff

 
Posted : 05/05/2020 10:45 am
Mark
 Mark
Posts: 27
Eminent Member
Topic starter
 

but in the example I posted, there is the same midi file of type 1 and transformed into type 0.
In my example, in the fifth column of type 0, the delta times have been changed, from 512 to 0 and 256 to 0: by what criterion?
[code type=markup]
type 0 type 1
4D 77 84 114 0 0 4D 77 84 114 0 0
90-C4 144 60 100 0 0 90-C4 144 60 100 >> 512 << 0
90-E4 144 64 100 0 0 90-E4 144 64 100 >> 256 << 0
[/code]

 
Posted : 05/05/2020 10:57 am
Geoff
Posts: 1039
Noble Member
 

I don't know.

I'm working from the midi file you sent me.

I've converted this to .TXT. Your midi file is Type 1, the converted/displayed data is in time order. i.e. as per Type 0 file

My data, as regards the items and the delta time, looks like your Type 0 example. The Type 1 data does not make sense to me.

The data you had before agrees with the type 0 version just now, and NOT the type 1 version. Where has the type 1 version come from? I would say it is not correct, or it is NOT the same data?

Geoff

 
Posted : 05/05/2020 11:14 am
Mark
 Mark
Posts: 27
Eminent Member
Topic starter
 

it is the same midi file converted to type 0 with a program found on the network: https://www.gnmidi.com/gn1to0.zip

 
Posted : 05/05/2020 11:23 am
Geoff
Posts: 1039
Noble Member
 

Err??

I've followed the link you give.

This says that the prog is to convert midi file to .WAV. Does not say anything about converting type 1 file to type 0 file. OK, I understand that the process to create the .WAV could involve an intermediate step of creating a type 0 file, but I'd more expect that this would all happen in memory.

I have a prog to convert type 1 to 0 anyway, it's part of the same package as the prog I use to convert a .mid file to a .TXT for easier reading/study. But I'd be far more interested in why your file has got messed up.

Back to a question that I keep asking, and you don't answer.

I assume that you have played your test midi file, using a prog you have NOT written (which is ??) and it plays correctly - that's using the word 'correct' in it's broadest sense.

I assume that if you play the file using the latest version of YOUR prog, it still does NOT play correctly. Is it sounding any better (??) now than it was?

When I play your midi file, I hear a short sequence of chords, about 5 secs, and it sounds like it could be correct. Certainly no cacophony!! Does that sound right to you. SynthFont shows the file as 0:05. (m:ss) Is that timing OK?

Oh, one thing. When converting type 1 file to type 0 file, some of the bytes might be different, or extra. If your data is using 'running status'? One version might allow running status in certain situations, and the other version might not. Just asking.

Geoff

 
Posted : 05/05/2020 1:31 pm
Mark
 Mark
Posts: 27
Eminent Member
Topic starter
 

sorry I put a wrong link, I used this program for the conversion from 1 to 0: https://www.gnmidi.com/gn1to0.zip and after the conversion from 1 to 0, even in my program, the midi file sounds correctly.
However, if you look closely, the program "gn1to0", during the conversion, modifies the deltatime of all events: this is the point to understand, how does it do?

Yes, all 0/1 versions of the midi files play correctly with Windows Media Player, not with my program due to the delta time which in my opinion must be recalculated.

The duration of the midi file is about 4 seconds.

 
Posted : 05/05/2020 10:34 pm
Mark
 Mark
Posts: 27
Eminent Member
Topic starter
 

however I understood where the problem is.
I'm going to work.

For the moment, thank you Geoff, I will post the solution for others who may have the same problem in the future.

 
Posted : 06/05/2020 2:29 am
Geoff
Posts: 1039
Noble Member
 

Mark,

Just to clarify/correct, when you convert data from type 1 to type 0 midi file, all the events will be on the one track, so yes, the indiv delta times will change, and this change would be done by the conversion process. However, the accumulated delta time for each event should end up the same as it was for the type 1 file when both are processed for playback. As far as the midi data is concerned, there should not be any 'calculation' other than simple addition.

So yes, the delta times will have been changed, so that they will add up correctly so that each event will remain in the correct relative position for playback. The 512 marked in your example above MUST be an error, maybe in your translation of the data? However, if that value is a delta time in the type 1 file then that file may NOT play correctly.

Geoff

 
Posted : 06/05/2020 1:48 pm
Mark
 Mark
Posts: 27
Eminent Member
Topic starter
 

sorry Geoff but MidiSoft Studio with notes from: 1/8, 1/4, 2/4, 4/4 produces the following delta times:
[code type=markup]
Channel Note Velocity Delta Time
90-C4 60 100 0 1/8 note
80-C4 60 100 128
90-C4 60 100 256 1/4 note
80-C4 60 100 256
90-C4 60 100 128 2/4 note
80-C4 60 100 512
90-C4 60 100 256 4/4 note
80-C4 60 100 1028
[/code]

 
Posted : 06/05/2020 10:41 pm
Geoff
Posts: 1039
Noble Member
 

Well, I don't know. The numbers you are now presenting do not make any sense, or they are not what we are assuming they are.

MidiSoft Studio may be presenting other info? But what?

The data you show. Are you copying this data from a screen. Is ALL the data copied, or is there something there that you have calculated/added? Some systems do show the length of the note as well as the delta time. If the system plays the data correctly, then it must have the correct timings, in the correct order, byt the data you show is either NOT correct data, or is in the wrong order (but the actual data regardless of the timings does seem to be in the right order).

I fully understand, if the system you are using is offering suct wierd data, and you are trying to make sense of it to get your own process working, it must be VERY confusing!!

All systems that I've used display the EVENT LIST (which is what that sort of data shown like that would be called) in a standard way. This is usually with the delta time in decimal followed by the note data which can be in either hex or decimal, and some system may show a note length with the Note On event, usually in decimal. Track and Channel date would notmally be there as well, these are not so important for your data. Some of this data is as per the midi file, other data is converted or calculated (added). But nothing should be changed from what's in the midi file.

Could you send me the midi file that the data above comes from? Supposedly??

Geoff

 
Posted : 07/05/2020 5:34 am
Mark
 Mark
Posts: 27
Eminent Member
Topic starter
 

the example midi file. Warning, it's a file without a musical sense, I only use it for tests.

hex dump file

[code type=markup]
4D 54 68 64 00 00 00 06 00 01 00 02 01 80 4D 54 72 6B 00 00 00 23 00 FF 58 04 04 02 60 08 00 FF 7F 03 00 00 41 00 FF 7F 05 00 00 77 0E 00 00 FF 51 03 07 A1 20 00 FF 2F 00 4D 54 72 6B 00 00 00 2B 00 90 3C 64 81 00 80 3C 64 82 00 90 3C 64 82 00 80 3C 64 81 00 90 3C 64 84 00 80 3C 64 82 00 90 3C 64 88 04 80 3C 64 00 FF 2F 00
[/code]

meaning

[code type=markup]
4D 54 68 64 00 00 00 06 00 01 00 02 01 80
4D 54 72 6B 00 00 00 23
00 delta time
FF 58 04 04 02 60 08
00 delta time
FF 7F 03 00 00 41
00 delta time
FF 7F 05 00 00 77 0E 00
00 delta time
FF 51 03 07 A1 20 00
FF 2F 00 end of track
4D 54 72 6B 00 00 00 2B
00 delta time
90 3C 64 note ON
81 00 delta time
80 3C 64 note OFF
82 00 delta time
90 3C 64 note ON
82 00 delta time
80 3C 64 note OFF
81 00 delta time
90 3C 64 note ON
84 00 delta time
80 3C 64 note OFF
82 00 delta time
90 3C 64 note ON
88 04 delta time
80 3C 64 note OFF
00 delta time
FF 2F 00 end of track
[/code]

 
Posted : 07/05/2020 6:22 am
Geoff
Posts: 1039
Noble Member
 

Mark,

As far as I can tell, the midi file is fine. Your transfer of the data therein seems OK. When I do a DECODE listing from the midi file, everything is fine (attached).

I'm not aware of any problem with this. Are you still seeing a problem. If it's showing in your process, or in a system you have, maybe there's some problem there?

Geoff

 
Posted : 07/05/2020 10:24 am
Mark
 Mark
Posts: 27
Eminent Member
Topic starter
 

finally the problem has been solved.
To convert a midi file from type 1 to type 0 you must:
a) calculate the absolute time of each track
b) sort the tracks for absolute time and I, for punctuation, also for note
c) the delta times must be recalculated which must correspond to the original ones before reordering.

I have found a method that is not very effective, but I am working on it.

Thank you so much Geoff for your valuable help

 
Posted : 22/05/2020 11:56 pm
Page 3 / 3
Share: