fbpx
  Saturday, 02 May 2020
  44 Replies
  8.5K Visits
0
Votes
Undo
  Subscribe
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
2 years ago
·
#5189
0
Votes
Undo
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
2 years ago
·
#5190
0
Votes
Undo
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.
2 years ago
·
#5192
0
Votes
Undo
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
2 years ago
·
#5193
0
Votes
Undo
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
2 years ago
·
#5195
0
Votes
Undo
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
2 years ago
·
#5199
0
Votes
Undo
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.

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
2 years ago
·
#5201
0
Votes
Undo
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.
2 years ago
·
#5202
0
Votes
Undo
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)

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


(2)

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

2 years ago
·
#5203
0
Votes
Undo
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
2 years ago
·
#5204
0
Votes
Undo
I'm working on it
2 years ago
·
#5205
0
Votes
Undo
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?

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
2 years ago
·
#5207
0
Votes
Undo
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
2 years ago
·
#5208
0
Votes
Undo
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?

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
2 years ago
·
#5209
0
Votes
Undo
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
2 years ago
·
#5210
0
Votes
Undo
it is the same midi file converted to type 0 with a program found on the network: https://www.gnmidi.com/gn1to0.zip
2 years ago
·
#5211
0
Votes
Undo
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
2 years ago
·
#5213
0
Votes
Undo
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.
2 years ago
·
#5220
0
Votes
Undo
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.
2 years ago
·
#5223
0
Votes
Undo
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
2 years ago
·
#5228
0
Votes
Undo
sorry Geoff but MidiSoft Studio with notes from: 1/8, 1/4, 2/4, 4/4 produces the following delta times:

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
  • Page :
  • 1
  • 2
  • 3
There are no replies made for this post yet.
Be one of the first to reply to this post!