midi to cv conversion
Fraser, Colin J
Colin.Fraser at scottishpower.plc.uk
Wed Dec 8 19:25:25 CET 1999
> -----Original Message-----
> From: Grant Richter [mailto:grichter at execpc.com]
> Sent: 08 December 1999 16:52
> To: Beszedes Arpad; synth-diy at mailhost.bpa.nl
> Cc: harrybissell at prodigy.net
> Subject: Re: Last word on caps
>
>
> For MIDI>CV demultiplexers, you want to be able to
> update the entire channel set in 1 millisecond.
> So to determine the update rate, take one millisecond and
> divide by the number of output channels.
>
> A maximum of 4 milliseconds latency from note-on to
> output is generally acceptable, but the primary source of latency
> will be software, so the hardware should be as fast
> as possible so as to not add additional latency.
Some observations about midi to cv software...
You can get away with a slower demux refresh rate than you might think -
it's more important to get the gate signal high as soon as possible after
the midi message arrives, to get tight timing.
You will perceive slack timing long before you notice a few milliseconds of
tuning error at the start of a note.
Think about the size of the s&h cap in a typical analogue keyboard.
Do you notice the slew at the start of every note ?
If you immediately update the demux channel to be changed as you process the
note on message you will get better cv change response.
Then refresh rate is not so critical, and you can spend the money you saved
on a faster processor on beer instead.
Most midi processing software I've looked at uses an interrupt routine to
receive the midi input data, and store it in a buffer.
Then the normal program loop pulls data out of the buffer and processes the
note on/off messages.
This is a sure way to get sloppy timing !
With a fast enough processor, it should be possible to receive the midi
data, and act on it immediately - updating a table of output channel values
and gate/slide latches etc. Then the normal program loop handles nothing
more than the demux refresh.
If you can be sure that the interrupt routine will complete in less than the
time it takes to receive the next midi byte (0.32ms), it should be possible
to avoid the need for buffering of midi data and processing it in the normal
program loop altogether.
Having said all that, the way things are going with the price of small
microcontrollers and high resolution serial DACs, I think I'll end up with
lots of low cost single or dual channel cv convertors for each synth with no
demux going on at all, and ultra fast response times.
Colin f
More information about the Synth-diy
mailing list