Controlling analog synths with computers

[gstopp at fibermux.com]

     Now we're on a roll! I happened to mention this thread to my wife last 
     night over sushi, and she told me I was a fool. Now actually that 
     happens fairly often anyway - you know, that man/woman thing - but 
     this time it was about computer languages. (See she writes embedded 
     token ring drivers in C for a living, sneaking in assembly whenever 
     she can). Anyway if the word "QuickBasic" is anywhere in the 
     conversation she won't stoop down to my level. Gotta love her.
     
     Anyway she totally agrees that assembly is the way to go, that parsing 
     the MIDI protocol demands a state machine, and that if you want a fast 
     state machine then you'd best use assembly. She also thinks that my XT 
     would make a nice planter.
     
     See my approach to all this is that since the PC has that monitor and 
     that keyboard on it, that it would be a shame to let it just sit there 
     with a blank screen while some assembly routine drives the DAC - why 
     not have some moving color bar graphs jumping around showing note 
     activity on each MIDI channel as the music plays? Or something neat 
     like that? I'll be damned if I write all *that* in assembly. That's 
     what the higher level languages are for.
     
     Okay write some assembly I/O routines, and write the app in C, and 
     link the OBJ's in the makefile. I was hoping to get around this. I had 
     this notion of using the program, and then saying "hey wait a minute" 
     and stopping the execution and dropping into the editor and making 
     some change and then re-starting the program and being all happy with 
     the new tweak. My wife just borrowed a copy of TurboC (she says she 
     has always liked the Borland environment) for a contractor job, and 
     I'm wondering if it will even fit on my XT.
     
     The MPU-401 has two modes of operation - "UART mode", and "composer 
     mode". Composer mode is the default mode. In this mode the MPU 
     off-loads the PC's CPU by taking care of all MIDI functions like 
     timing and running status and such. However I've never bothered to 
     grok the somewhat cryptic command set to use this mode. I seem to 
     remember that it is *not* straightforward. Maybe I should read the 
     programming manual again (heck, it's on the bookstand in our 
     bathroom). UART mode turns the MPU into a raw data port into the MIDI 
     line which is the approach that I took because UARTs I'm used to. I'm 
     sure that composer mode exists in the first place due to the lack of 
     sufficient speed of PC's at the time. Exactly my problem at the 
     moment.
     
     Nowadays the MIDI ports on Soundblasters and such advertise "MPU-401 
     compatibility" but I suspect that means that their UART I/O addresses 
     are at 330H and 331H, like the 401 in UART mode. I'll bet they don't 
     even bother with composer mode emulation anymore. Does anybody know 
     the facts on this? I'm just guessing.
     
     (I suppose I should dust off my copy of Jim Conger's book "C 
     Programming for MIDI"....)
     
     There are a couple of uses for my DAC hardware that I'm considering, 
     the three biggies of which are poly mode (driving multiple voices as 
     chords on a single MIDI channel) mono mode (driving a bunch of 
     seperate synthesizers each on it's own MIDI channel), and custom mode 
     where each DAC channel can be mapped to some arbitrary parameter in 
     the MIDI stream. It would be nice if all these functions were part of 
     one overall program, perhaps with a menu to select the modes. In 
     addition, within each mode there should be some sub-menus or something 
     to select parameters (especially in the mapping mode). So - high level 
     programming would be essential. Some may suggest Visual C or Visual 
     BASIC but that would require a new PC anyway to run Windows. Now we're 
     back to trashing the XT.
     
     But if I trash the XT and move up to a more modern platform, I can 
     just keep on using my QuickBasic code that already exists. Ha ha, the 
     easy way out! Long, long ago I wrote a Datascope program in QB that 
     parses the MIDI line and prints out text descriptions of each message, 
     with fields for the values and all that. It was in the writing of that 
     code that I learned the proper structure of when to do what for this 
     particular protocol. Let me tell you, I learned. And let me tell you 
     that figuring out how to handle Real Time was the biggest pain in the 
     butt. The code went through many iterations until it got to where it 
     is (it is a state machine, BTW, lots of globals).Anyway I took this 
     source, hacked out the decoding, and added a few lines in the 
     note-on/note-off functions, and the DAC control was done! This is what 
     I want - a kernel that is easy to adapt.
     
     As for the concept of trade secrets - there may be some validity to 
     the idea that propigating a successful MIDI parsing algorithm on an 
     email list can undercut some niche market sales. Do some of you really 
     feel this way? I mean yes I saw the smileys but there's a grain of 
     truth in every joke. It occurs to me that if somebody wants to start a 
     competitive venture, there's a lot more to it than just knowing the 
     science. If fact that's usually the easy part. On the other hand there 
     is the idea that if a musician can do something on his own then he 
     won't need to buy the product. That may be true also, but for me at 
     least I know that this will not stop me from buying some more MIDI-CV 
     converters. For example, Kyle Jarger's CV-3 is just too powerful, with 
     too many features, to duplicate on my own - it's much more cost 
     effective to fork over the cash and be done with it. In fact, doing 
     all this home-brew stuff just makes me apprectiate boxes like that 
     even more.
     
     Anyway sorry for the windbag mode, but I still want to talk about MIDI 
     parsers - okay another post. That'll give you a chance to stop me if I 
     uncover too many trade secrets... :)
     
     - Gene
     gstopp at fibermux.com


______________________________ Reply Separator _________________________________
Subject: Re: Re[2]: Controlling analog synths with computers (fwd)
Author:  "J.D. McEachin" <jdm at synthcom.com> at ccrelayout
Date:    11/22/96 12:18 AM


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