MIDI-timings the everlasting confusion ?
MIDI-timings the everlasting confusion ?
Hi,
I'm trying to understand how MIDI-timings do/should work.
I read about players having a resolution of 960 ticks per beat (whatever ticks should mean) at 250 bpm.
So that should play 250/60 = 4,1666... beats per second and so 4,1666 * 960 = 4000 ticks per second ???!!!
How do they get those 4000 ticks per second, which should be delivered by a stable timer ?
As far as I know there is no stable timer (under windows) delivering more then 1000 ticks per second.
And, the resolution of this timer can only be set by dividing it with a integer value (2, 3, 4 ...).
Furthermore in many midi files are different tempo's used. (112bpm, 113bpm and whatever).
They are expressed in micro seconds ???!!!
What stable timer can do that ?
Tempo 112 BPM, at 535714 microseconds/quarter-note
Tempo 75 BPM, at 800000 microseconds/quarter-note
Tempo 154 BPM, at 389610 microseconds/quarter-note
How can a stable timer of 1000 ticks per second replay precise those different bpm's ?
113/60 = 1,88333 beats per second.
So, our 1000 ticks per second resolution, should be set to deliver :
1000/1,88333 = 530,97345 ticks
How can all these floating point values become used as a stable timing ?
My humble opinion says, live with it.
Or am I wrong ?
Thanks.
I'm trying to understand how MIDI-timings do/should work.
I read about players having a resolution of 960 ticks per beat (whatever ticks should mean) at 250 bpm.
So that should play 250/60 = 4,1666... beats per second and so 4,1666 * 960 = 4000 ticks per second ???!!!
How do they get those 4000 ticks per second, which should be delivered by a stable timer ?
As far as I know there is no stable timer (under windows) delivering more then 1000 ticks per second.
And, the resolution of this timer can only be set by dividing it with a integer value (2, 3, 4 ...).
Furthermore in many midi files are different tempo's used. (112bpm, 113bpm and whatever).
They are expressed in micro seconds ???!!!
What stable timer can do that ?
Tempo 112 BPM, at 535714 microseconds/quarter-note
Tempo 75 BPM, at 800000 microseconds/quarter-note
Tempo 154 BPM, at 389610 microseconds/quarter-note
How can a stable timer of 1000 ticks per second replay precise those different bpm's ?
113/60 = 1,88333 beats per second.
So, our 1000 ticks per second resolution, should be set to deliver :
1000/1,88333 = 530,97345 ticks
How can all these floating point values become used as a stable timing ?
My humble opinion says, live with it.
Or am I wrong ?
Thanks.
Yeah I know, but keep in mind ... Leonardo da Vinci was also an autodidact.
Re: MIDI-timings the everlasting confusion ?
Maybe ElapsedMicroseconds() can help you (Windows only):Joris wrote:As far as I know there is no stable timer (under windows) delivering more then 1000 ticks per second.
Code: Select all
Procedure.q ElapsedMicroseconds ()
Protected Frequency.q
Protected Counter .q
QueryPerformanceFrequency_(@Frequency)
QueryPerformanceCounter_ (@Counter)
ProcedureReturn Counter * 1000000 / Frequency
EndProcedure
time = ElapsedMicroseconds()
time = ElapsedMicroseconds() - time
Debug time
sorry for my bad english
Re: MIDI-timings the everlasting confusion ?
@Josh, if I run this, it doesn't seem to deliver a very stable timing.
How else should it be adapted ?
Code: Select all
Procedure.q ElapsedMicroseconds()
Protected Frequency.q
Protected Counter .q
QueryPerformanceFrequency_(@Frequency)
QueryPerformanceCounter_ (@Counter)
ProcedureReturn Counter * 1000000 / Frequency
EndProcedure
OpenConsole()
Delay(100)
Global a.i
time = ElapsedMicroseconds()
Repeat
a=ElapsedMicroseconds() - time
If Not Mod(a, 10000)
PrintN(Str(a))
EndIf
Until Inkey()
Input()
Yeah I know, but keep in mind ... Leonardo da Vinci was also an autodidact.
Re: MIDI-timings the everlasting confusion ?
I have no information on the use of timers (unfortunately) but here is some reference info on the timing of MIDI events for those that aren't up on these things:
I am also interested in methods of reliable timing or sequencing short duration events such as sound playback.
Ticks can be converted to playback seconds as follows:
ticks_per_quarter = <PPQ from the header>
µs_per_quarter = <Tempo in latest Set Tempo event>
µs_per_tick = µs_per_quarter / ticks_per_quarter
seconds_per_tick = µs_per_tick / 1000000
seconds = ticks * seconds_per_tick
I am also interested in methods of reliable timing or sequencing short duration events such as sound playback.
Re: MIDI-timings the everlasting confusion ?
I don't think you need that kind of timing accuracy for MIDI playback.
Just keep a general counter for the midi timings and if the current time is equal to or has passed the time the midi event was scheduled, process it.
If you do it this way, individual midi events might be off a little but the individual errors won't add up.
Audio drivers always have a latency so it's never 100% accurate but if it's only off by a few milliseconds you shouldn't be able to hear the difference.
Just keep a general counter for the midi timings and if the current time is equal to or has passed the time the midi event was scheduled, process it.
If you do it this way, individual midi events might be off a little but the individual errors won't add up.
Audio drivers always have a latency so it's never 100% accurate but if it's only off by a few milliseconds you shouldn't be able to hear the difference.
Windows (x64)
Raspberry Pi OS (Arm64)
Raspberry Pi OS (Arm64)
Re: MIDI-timings the everlasting confusion ?
Yeah Wilbert, I still use the standard windows timer, but there are so many complains to find on the www about these timings, which led me to try find a better way then saying 'live with it'.
So did I found once this code. Showing a microsecond timer :
viewtopic.php?f=12&t=38575
Yet, it's hard to say which one is more stable, as both compared timers are in one system.
To me that's not the best way to compare them. It may also be that the Milliseconds-timer is not precise. Still I have no clue...
I kept using the windows milli-second timing (timeGetTime_()).
To set precise timings for different bpm's looks easier to do with a more accurate timer. But if not stable...
Probably still accurate to say 'live with it'.
So did I found once this code. Showing a microsecond timer :
viewtopic.php?f=12&t=38575
Yet, it's hard to say which one is more stable, as both compared timers are in one system.
To me that's not the best way to compare them. It may also be that the Milliseconds-timer is not precise. Still I have no clue...
I kept using the windows milli-second timing (timeGetTime_()).
To set precise timings for different bpm's looks easier to do with a more accurate timer. But if not stable...
Probably still accurate to say 'live with it'.
Yeah I know, but keep in mind ... Leonardo da Vinci was also an autodidact.
Re: MIDI-timings the everlasting confusion ?
Wilbert what is the most accurate and stable timer (resolution) on mac OS ?
Does anyone know how this is on Linux too ?
Does anyone know how this is on Linux too ?
Yeah I know, but keep in mind ... Leonardo da Vinci was also an autodidact.
Re: MIDI-timings the everlasting confusion ?
You can take a look at this thread ...Joris wrote:Wilbert what is the most accurate and stable timer (resolution) on mac OS ?
viewtopic.php?f=19&t=49359
Windows (x64)
Raspberry Pi OS (Arm64)
Raspberry Pi OS (Arm64)
- NicTheQuick
- Addict
- Posts: 1227
- Joined: Sun Jun 22, 2003 7:43 pm
- Location: Germany, Saarbrücken
- Contact:
Re: MIDI-timings the everlasting confusion ?
ElapsedMilliseconds() on Linux is exact down to 1 ms. The following code returns one line every millisecond. (Use executable format "console" in the compiler options)
Code: Select all
OpenConsole()
PrintN("Go")
Delay(1000)
a = ElapsedMilliseconds() + 100
count = 0
old = -1
Repeat
b = ElapsedMilliseconds()
If b > a
Break
EndIf
If b <> old
count + 1
PrintN(Str(100 - a + b))
old = b
EndIf
ForEver
PrintN("Got " + count + " different values within 100ms")
Input()
CloseConsole()
The english grammar is freeware, you can use it freely - But it's not Open Source, i.e. you can not change it or publish it in altered way.
Re: MIDI-timings the everlasting confusion ?
+1wilbert wrote:I don't think you need that kind of timing accuracy for MIDI playback.
Just keep a general counter for the midi timings and if the current time is equal to or has passed the time the midi event was scheduled, process it.
If you do it this way, individual midi events might be off a little but the individual errors won't add up.
Audio drivers always have a latency so it's never 100% accurate but if it's only off by a few milliseconds you shouldn't be able to hear the difference.
Joris I'm not clear what you're trying to do with these MIDIs (play back audio?) but it shouldn't require a micro-second accurate software timer.
Think about CD audio or WAV playback... ~44100 samples/second. You don't need a software timer accurate to 44.1kHz, you typically just pre-fill a buffer and let the hardware drive it out accurately.
Re: MIDI-timings the everlasting confusion ?
@kenmo I'm just bussy with midi only (for now).
It's because I had some trouble with accurate timing, I ran into more trouble by starting to read about it again. Many words about microseconds ???? Never seen a stable version but still...
I've got my problem solved and you people made me again a bit more sure.
I have to burn some books now ...
P.s. I know about audio and the use of bufferings.
Thanks all.
It's because I had some trouble with accurate timing, I ran into more trouble by starting to read about it again. Many words about microseconds ???? Never seen a stable version but still...
I've got my problem solved and you people made me again a bit more sure.
I have to burn some books now ...
P.s. I know about audio and the use of bufferings.
Thanks all.
Yeah I know, but keep in mind ... Leonardo da Vinci was also an autodidact.
Re: MIDI-timings the everlasting confusion ?
Just my two cents about midi stability: it isn't stable in the first place..³. 16 channels with tons of simultaneous cc values can easily choke the bandwidth AFAIR. You probably know this.... But I always like to have a dig at midi.... CV and gate (and a ton of cables!) for the win....
Seriously tho it's strange that there was never a proper successor to midi. Now we have OSC and the like... Not used it... But I assume it's better than 31200 bps or whatever midi is.
All this said: I STILL USE MIDI
Seriously tho it's strange that there was never a proper successor to midi. Now we have OSC and the like... Not used it... But I assume it's better than 31200 bps or whatever midi is.
All this said: I STILL USE MIDI
Proud supporter of PB! * Musician * C64/6502 Freak
Re: MIDI-timings the everlasting confusion ?
The problem with MIDI is imo the use of different hardware timers.
Use one stable.
Use one stable.
Yeah I know, but keep in mind ... Leonardo da Vinci was also an autodidact.