[sdiy] MIDI spec

[René Schmitz]

Hi everyone!

At 10:31 04.12.02 -0000, Colin f wrote:
>I'm going about things in a slightly different way in my current convertor
>project (which is taking ages, but anyway...)
>Given that midi bytes are separated by at least 0.32 ms, I don't believe you
>need a buffer any bigger than 3 bytes for all but system exclusive messages.
>If you can't process a 3 byte message in ~ 0.1 ms, your CPU is too slow
>(unless you're doing something really complex like polyphonic voice
>assignment, but even then, I'd still argue that if you're polling in a loop
>for time critical events like the arrival of a midi message, you system is
>not sufficiently real-time).

I make a similar argument, but yet a different approach: The main loop polls the 
UART, and everything time critical (S&H refresh, LFO whatever) is done in the 
timers ISR. Of course the midi parser and the handling routines must be finished 
within the time it takes to transmit a byte. Likewise for the timer ISR. But 
thats really a lot of cycles. 320uSec is almost an eternity, if you have an 
AVR @ 4Mhz thats about 1000 instructions. Plenty if you program in Assembler. 
And in practice, the time is even longer, because the things that may 
take long are in the handlers. And these only get called if a full message 
has been decoded, when its likely that the line will be idle for a little while. 

>In practice, it's not even a buffer - it's a running status register, two
>data byte registers, and flags to indicate whether the system is waiting for
>a new status byte, the first data byte, or the second data byte.
>So basically, I'm processing the arriving midi messages in the serial
>interrupt routine itself (once they are complete), and updating state tables
>for the cv/gate outputs.

In my parser the state is not explicitly in a register, but implicitly, because 
the parser can call the UART polling routine in various places. The state is thus 
preserved in the return address on the stack. Polling is no problem, we don't have 
anything to do in the main loop until the byte is coming in anyway. 

>I put the S&H refresh code into the main loop. It doesn't need the rock
>solid regularity of a timer event, and IMO it's more important to be acting
>on received messages than it is to be updating caps.
>If you want to add timer interrupts for EGs, LFOs etc, the routine would
>need to take less time than the length of one midi byte, to prevent the
>serial IRQ routine potentially missing a byte, but again, if this is not the
>case, your CPU is not fast enough to do the job in real-time.

Exactly! No amount of buffering can help if the pace of the incoming data is 
greater on the average than what you can process. 

Cheers,
 René
-- 
uzs159 at uni-bonn.de
http://www.uni-bonn.de/~uzs159