MIDI-timings the everlasting confusion ?

[Joris]

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.

[Josh]

As far as I know there is no stable timer (under windows) delivering more then 1000 ticks per second.

Maybe ElapsedMicroseconds() can help you (Windows only):

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

You should check since which Windows version those both Apis are supported.

[Joris]

@Josh, if I run this, it doesn't seem to deliver a very stable timing.

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()

How else should it be adapted ?

[Demivec]

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:

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.

[wilbert]

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]

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'.

[Joris]

Wilbert what is the most accurate and stable timer (resolution) on mac OS ?
Does anyone know how this is on Linux too ?

[wilbert]

Wilbert what is the most accurate and stable timer (resolution) on mac OS ?

You can take a look at this thread ...
viewtopic.php?f=19&t=49359

[NicTheQuick]

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()

[kenmo]

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.

+1

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.

[Joris]

@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.

[oreopa]

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

[Joris]

The problem with MIDI is imo the use of different hardware timers.
Use one stable.