in the midi file dump below, I have ppqn = 480 and bpm = 120. For a 4/4 note I was expecting 1920 ticks for the first note, instead it's 1823 ticks; the remaining 97 ticks are part of the next ON note: why?
If I read 1823 instead of 1920 (480 * 4) from the file, how do I understand that it is a 4/4 note?
Thank you
If I read 1823 instead of 1920 (480 * 4) from the file, how do I understand that it is a 4/4 note?
Thank you
000000 4d 54 68 64 Chunk ("MThd")
000004 00 00 00 06 length (6)
000008 00 01 Format (1)
00000a 00 01 NumberOfTracks (1)
00000c 01 e0 TimeBase (480)
00000e 4d 54 72 6b Chunk ("MTrk")
000012 00 00 00 6d length (109)
delta : tick :
000016 00 ff 58 04 04 02 18 08 +0 = 0 : Meta:TimeSig (4/4, Metronome=24MIDICLK, 8/32=24MIDICLK)
00001e 00 ff 59 02 00 00 +0 = 0 : Meta:KeySig (0 major = "C Maj")
000024 00 ff 51 03 07 a1 20 +0 = 0 : Meta:SetTempo (500000 = 120)
00002b 00 b0 79 00 +0 = 0 : CtrlChg (ch:1 CC#121(RstALlCtl) val:0)
00002f 00 c0 00 +0 = 0 : ProgChg (ch:1 pg:0)
000032 00 b0 07 64 +0 = 0 : CtrlChg (ch:1 CC#7 (ChVolum) val:100)
000036 00 0a 40 +0 = 0 : CtrlChg (ch:1 CC#10 (Pan ) val:64)(RunStat)
000039 00 5b 00 +0 = 0 : CtrlChg (ch:1 CC#91 (Eff1Dep) val:0)(RunStat)
00003c 00 5d 00 +0 = 0 : CtrlChg (ch:1 CC#93 (Eff3Dep) val:0)(RunStat)
00003f 00 ff 21 01 00 +0 = 0 : Meta:PortPrefix
000044 00 90 40 50 +0 = 0 : NoteOn (ch:1 note:64 velo:80)
000048 8e 1f 40 00 +1823 = 1823 : NoteOn (ch:1 note:64 velo:0)(RunStat)
00004c 61 40 50 +97 = 1920 : NoteOn (ch:1 note:64 velo:80)(RunStat)
00004f 87 0f 40 00 +911 = 2831 : NoteOn (ch:1 note:64 velo:0)(RunStat)
000053 87 71 40 50 +1009 = 3840 : NoteOn (ch:1 note:64 velo:80)(RunStat)
000057 83 47 40 00 +455 = 4295 : NoteOn (ch:1 note:64 velo:0)(RunStat)
00005b 8b 39 40 50 +1465 = 5760 : NoteOn (ch:1 note:64 velo:80)(RunStat)
00005f 81 63 40 00 +227 = 5987 : NoteOn (ch:1 note:64 velo:0)(RunStat)
000063 8d 1d 40 50 +1693 = 7680 : NoteOn (ch:1 note:64 velo:80)(RunStat)
000067 71 40 00 +113 = 7793 : NoteOn (ch:1 note:64 velo:0)(RunStat)
00006a 8e 0f 40 50 +1807 = 9600 : NoteOn (ch:1 note:64 velo:80)(RunStat)
00006e 38 40 00 +56 = 9656 : NoteOn (ch:1 note:64 velo:0)(RunStat)
000071 8e 48 40 50 +1864 = 11520 : NoteOn (ch:1 note:64 velo:80)(RunStat)
000075 1b 40 00 +27 = 11547 : NoteOn (ch:1 note:64 velo:0)(RunStat)
000078 8e 65 40 50 +1893 = 13440 : NoteOn (ch:1 note:64 velo:80)(RunStat)
00007c 0d 40 00 +13 = 13453 : NoteOn (ch:1 note:64 velo:0)(RunStat)
00007f 01 ff 2f 00 +1 = 13454 : Meta:EndOfTrack
I am not knowledgeable about midi, but when recording live play noone manage to play exact notedivisions/ticks within the chosen ppq and bpm, that is for transcribed sheetnotes ,if you write music?
And it would not sound musical if one did.
I guess you just round the timing value, number of ticks between note on->note off to the nearest full note partitioned value?
And it would not sound musical if one did.
I guess you just round the timing value, number of ticks between note on->note off to the nearest full note partitioned value?
sorry Jonas, but that dump of a midi file was not obtained with a live recording, it was written with musescore, so I expected a very precise result. However, if from a midi file I read 1823 ticks instead of 1920 ticks, with ppqn = 480, it becomes difficult to establish that it is a 4/4 note.
Thanks anyway for the information.
Thanks anyway for the information.
Jonas is quite right.
Most/many sequencing programs do not enter a fuil note but usually about 95% of the full value.
You'll find that a quarter note is about 456 ticks, a half note about 912.
Some sequencers allow you to set the percentage duration.
I suspect that Musescore will change the duration to 100% if you mark the music as being played Legato.
Most/many sequencing programs do not enter a fuil note but usually about 95% of the full value.
You'll find that a quarter note is about 456 ticks, a half note about 912.
Some sequencers allow you to set the percentage duration.
I suspect that Musescore will change the duration to 100% if you mark the music as being played Legato.
sorry Jonas, but that dump of a midi file was not obtained with a live recording, it was written with musescore, so I expected a very precise result. However, if from a midi file I read 1823 ticks instead of 1920 ticks, with ppqn = 480, it becomes difficult to establish that it is a 4/4 note.
Thanks anyway for the information.
I think you just calculate the tick amounts for the full note given PPQ and BPM and calculate partial note ticks as fractions, and then you compare which number of ticks closest to the "recorded" value. So for PPQ 480 and BPM 120 it becomes how close your value is to the below that decide what note value it have.
1920=1920/1, 960=1920/2, 480=1920/4, 240=1920/8, 120=1920/16,60=1920/32, 30=1920/64
At least that is the way i should do it.
But if the ticks just between.like 360 ticks... Well i know to little about sheet music to know howto handle that. I have a feeling though when in doubt shorten the note.
I will be a little heretic here at midi association another way ot think of it is simply use BPM, and use highest possible "realtime" recording values stored. At playup you will have a maximum polling speed depending on hardware. Changing BPM is a fractional change of your "recording".
BPM is of course just the metronome speed "and also the playup speed" changing between two BPM is a fractional timechange.
PPQ is really not necessary unless "your playup use ticks" i do not think i will rather maximum pollling speed, so there is still ticks of sort but they are not connected to "note length".
I guess you could say the polling speed of the realtime clock is the resolution of the recording, but it is not variable.
I would say it is probably more analog way to do things, "less quantisation?"
Ok enough of heretic rants for the day.
BPM is of course just the metronome speed "and also the playup speed" changing between two BPM is a fractional timechange.
PPQ is really not necessary unless "your playup use ticks" i do not think i will rather maximum pollling speed, so there is still ticks of sort but they are not connected to "note length".
I guess you could say the polling speed of the realtime clock is the resolution of the recording, but it is not variable.
I would say it is probably more analog way to do things, "less quantisation?"
Ok enough of heretic rants for the day.
Also, be prepared to find notes having values greater than their notated length, e.g. 481 or 961, etc.
When using various synths or VST sample players, in order to get musical phrases to sound correct, notes within a phrase are overlapped beyond the start of the next note, in order to cut out the attack portion of succeeding notes. Within such phrased sequences one will often find the MIDI controller CC#68 "on" (>64) before or during the first note of the phrase and off again during the last note. (Some VSTs use CC#64 for the same task.)
When using various synths or VST sample players, in order to get musical phrases to sound correct, notes within a phrase are overlapped beyond the start of the next note, in order to cut out the attack portion of succeeding notes. Within such phrased sequences one will often find the MIDI controller CC#68 "on" (>64) before or during the first note of the phrase and off again during the last note. (Some VSTs use CC#64 for the same task.)
triggering of note-off event is not the exact end of the note. it also has to go through the release phase. if it goes note-off at the end of the 1/4 note, it will spill over to the next one.
the interval amount you described is consistent with typical muscore generated midi files.
the interval amount you described is consistent with typical muscore generated midi files.
- Page :
- 1
There are no replies made for this post yet.
