Controlling analog synths with computers (fwd)

[J.D. McEachin]

At 02:25 PM 11/21/96 PST, gstopp at fibermux.com wrote:
>     <mock indignant tone mode on...>

Uh oh, brace yourselves for the battle royale between the hardware and software
dudes...

>     Oh sure write system clocks and program changes and sysex bytes all to 
>     your note CV DAC. OK just restrict your MIDI stream to note data. Now 
>     write the status byte then the note number then the velocity to your 
>     DAC, all within a millisecond, and leave the DAC value at whatever the 
>     last velocity was. Screw the notes.
>     
>     Nice MIDI-CV algorithm, guys.:)

Ummmm, doesn't the 401 have some prefiltering capabilities built in?  I'm
not a PC kind of guy (in more ways than one), but I'm pretty sure it does.
I've heard Neil talking about hacking 401 drivers to run several 401 boards,
some of that knowledge filtered in, but I'm no expert...
 
>     I want my MIDI-CV converter to comply fully with the MIDI spec. I want 
>     my MIDI-CV converter to parse the MIDI data so that I can plug it in 
>     to a sequencer's output and have it only pay attention to the messages 
>     that it's supposed to, and ignore those meant for other devices. My 
>     code does that - real time, system, channel, running status, all that. 
>     Handled properly, with recovery from invalid or incomplete messages 
>     even. It is not complicated but it is not pathetically limited either.
     
>     I want function calls and structured programming. I want labels and 
>     variables and operations in English. I want program flow and 
>     readability. I don't want spagetti assembler code. I'm not afraid of 
>     it, I grew up on it, I am above it.

Neil wrote the MIDI parser in Europa (and rewrote it when he failed to fully
consider the implications of system real time messages), so I'm sure he's
aware of this...     

>     Okay QuickBasic is a humorous language. I stand embarrased by that, 
>     you got me. But it's standard on any PC you walk up to, assuming it 
>     has fairly recent DOS. It's structured, it has user-defined functions, 
>     and it's real damn easy to get something done, goddammit. Quickly, 
>     goddammit.

You don't have to be embarassed about it - it's good for prototyping, coming
up w/ UIs, etc. - I just don't think it's the ideal REALTIME environment.
     
>     I've ported the algorithm over to C, and it works fine. There's no C 
>     compiler on my XT, and I don't even have it on 5 1/4" disks, and I 
>     don't think I'll find it on 5 1/4" disks. The XT has 360K drives. So I 
>     use what I've got, sue me.

Don't you have a compiler on your "real computer" that you use?  Set some
switches for 8088 compatibility, maybe?
 
>     If you ask me, defending a 4 meg XT that's *a hundred* times slower 
>     than a motherboard you can get for twenty bucks is where the funny 
>     part of all this is.
>     
>     <mock indignant tone mode off...>

No apologies necessary.  My hat is off to anyone that can make a boat anchor
make cool noises!
     
>     Seriously, guys, I'd love to discuss MIDI parsing. What I've done I 
>     made up myself, and it works great, but I've never even had a 
>     meaningful conversation about it with anybody before. For all I know 
>     there's an easier way and I'd like to compare notes (pun intended).

Shhh! Those are TRADE SECRETS, man!  We can say anything bout that!

;-}

State machine is the best way to do it.  I've seen it done in hardware, and
software.  Pass the realtime messages, go into another state for sysex and
running status...I guess I should look at this source code sometime...

Sorry, I'll admit, I'm NOT an expert on MIDI parsing.

JDM