[sdiy] MIDI spec

[Seb Francis]

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

I don't quite agree here.  In my MIDI2CV I am refreshing 15 S&Hs every 768us (approx 1.3KHz refresh/sample rate).  This means the timer triggers a CV-update interupt every 51.2us, and the CV-update routine itself takes a fair proportion of this to send the serial SPI data to the DAC, wait for DAC+opamps to settle before switching the MUX (the settle time of the S&H itself is done in between interrupts).  Then on top of this, the LFO/ENV/Portamento calculations are interspersed with some of the S&H updates in the same timer interrupt routine (because these need a solid sample rate of 1.3KHz to match the S&H updates).

So already only a fraction of the CPU time of the PIC is left for the main loop.  Then on top of that all key presses cause interrupts and updates of the LCD display (which can be really quite slow ~= 50us per char).  Ok, so I probably should handle all the display update stuff in the main loop, but it's more convenient to handle it as the key-debounce timer interrupts occur .. maybe I'll change this later though.

I agree in normal circumstances the MIDI message buffer is not needed, but when sending and handling 15CVs worth of MIDI CC messages, playing a few chords + some pitch bend, plus changing the LCD display, I can imagine the buffer could fall behind by a message or 2.  And if it does it's much better that that "note off" message is 1ms late rather than dropped!

I've thought about added an "idle time" page on the display which basically shows a moving average of how many cycles in each 768us timer-phase were free (i.e. just waiting for a new MIDI message to appear in the buffer).  The trouble with this idea is that the LCD display takes so long to update, it would only be possible to display a snapshot idletime, rather than a continuously updating display.  I think I will do this though, just out of interest to see how close I am getting to the limits of this PIC.  Luckily there's an 18 series PIC which is pin-for-pin compatible with the 16F877 I'm using - so if needed I can upgrade without any PCB or component changes (apart from maybe a 40MHz crystal :-)  Multiplications and divisions really eat up the CPU cycles in the 16 series PICs ...

BTW, my Sequential Circuits Six Trak has a lot of problems with too much MIDI data, and this uses a Z80 processor (not sure of the speed .. maybe 4MHz?) - but perhaps this was just bad programming on the part of SC..

Seb