Controlling analog synths with computers

[Magnus Danielson]

Hi All!

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

Keep loving here, it's probably worth it :)

I think you must crash her down to your level on the teaching side...

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

Either TurboC or maybe even TurboPascal will do. The Borland stuff has a fairly
simple interface towards the graphic which is one of the things I really miss
from the Borland environment now that I hack away in Unix. Pretty straigth
forward.

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

I have done this, writing assembly stuff towards the MPU-401 and C for the 
other
stuff. It works in the Borland environment.

You will have to dig up a fairly old TurboC for it to even run on your XT, but
if you develope on a 486/Penta you will be able to compile for the 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.

The command mode has it's advantages and it will let the MPU-401 CPU deal with
the MIDI stream task where as the PC (XT or whatever) can deal with the more
complex stuff. The command mode will actually take some of the work from you
since you will not have to deal with the same kind of time problem.
If you do not require compability with UART-mode only cards I think you should
use the command mode.

I have code for this if you are interested.

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

They only have UART-mode. You have to read the fine-print to find out. I 
suspect
nothing else unless specifically stated and then proved.

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

There are lot's of way to spend CPU cycles, there are fewer to used them 
wisely.

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

Faster hardware allways allows for dumb solutions to stick around longer, that
is a all too common problem in the buissness. However, in some cases it may
still be the best solution for the moment, I woun't argue with that.
Quality programing is not what it used to be...

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

It is the privilige of this list to enligthen people on how things work. I 
think
that bad knowledge on "basic" stuff like MIDI or whatever is actually more bad
for the industry than the competition. Rather than MIDI implementation 
subtelties is hearting the industry I think deeper dweeling into for instance
the Serge waveshaper is hearting more... but is really not that much of real
nuance really...

If and when we start to generate modules and systems that allmost anyone can
build and that cut the commercial products razorsharp of we migth discuss
trouble. But then there are commercial companies that are closer to that then 
we
are (Doepher and Paia without talking about products). If and when we have such
boxes around I think that it's up to the commerical forces to shape up rather
than attack us, since then they really just show how lazy they have been in
take further steps. They have after all a much better situation in creating
cheap gear than we have... we are hardly looking at doing ASICs rigth now, 
rigth?

Not that I see the humours side of things, but I think the serious debate is
not a problem, and if it is, well then we just form a company for the thing and
compete with then...

However we do anything I think it is wise to keep of patented solutions. And
sneaking code out of commercial products isn't nice and doesn't feel 
comteble...
unless given to us for the purpose of course...

Cheers,
Magnus