miskinis@aisg.enet.dec.com (John Miskinis) (02/06/91)
Hi, I bought an Atari 1040ST over 2 years ago with the intention of becoming a MIDI developer. I'm a full-time Software Engineer, and a part-time Atari user. I've been trying to develop a software system that would record MIDI data *PERFECTLY*. I started out by using a polling loop querying the OS to see if any MIDI bytes were in the (default) 128 byte buffer. This worked somewhat usefully, but aside from the bad nature of polling, I found that I would lose about 1 byte per 10,000. I hit the books, bought Mark Williams C, and wrote an interrupt routine that duplicates that the standard MIDI input code, but I write the bytes to MY buffer, and time-stamp each byte when it comes in. This method allows application freedom, as MIDI input will happen in the background. BUT I STILL LOSE DATA WHEN I MOVE THE MOUSE, AND VERY INFREQUENTLY WHEN I DON'T. Does anyone know how to get around this? Someone must, since there seems to be a lot of sequencing packages available for the ST. I've noticed that some of them mess up, but some seem to be VERY stable. I use a Roland TR505 for testing, with the tempo cranked up to the maximum, and a pattern that contains as many drum sounds that I can fit in on 16th note intervals... H E L P N E E D E D P L E A S E! T H A N K S I N A D V A N C E _John_
carter@cat27.cs.wisc.edu (Gregory Carter) (02/06/91)
miskinis@aisg.enet.dec.com (John Miskinis) Writes: ... This method allows application freedom, as MIDI input will happen in the background. BUT I STILL LOSE DATA WHEN I MOVE THE MOUSE, AND VERY INFREQUENTLY WHEN I DON'T. Does anyone know how to get around this? Someone must, since there seems to be a lot of sequencing packages available for the ST. I've noticed that some of them mess up, but some seem to be VERY stable. ------------------------------------------------------------------------------ Well what do you know, finally someone asks a question up my alley! John, I wrote some networking software for the midi port and ran into the same problem, the Bcon calls are too slow to retrieve information fast enough(In TOS 1.0 they are anyway, TOS 1.4/1.6 its a little better) from the input buffer. Solution? In increase your buffer size to about 4K, for really TAXING operations, increase to 16K. I use an 8K buffer and don't have any problems at all. Real time sequencing might be a different problem though. An example in Mark Williams C that shows you how to do this is in there, but it is used with the aux: port instead of the midi: port. --Good luck, --Gregory ------------------------------------------------------------------------------ OK OK OK, I know I am suppose to be at class right now, but gosh I love reading news OK. ------------------------------------------------------------------------------
sstreep@next.com (Sam Streeper) (02/07/91)
In article <3901@ryn.mro4.dec.com> miskinis@aisg.enet.dec.com (John Miskinis) writes: > > I hit the books, bought Mark Williams C, and wrote an interrupt >routine that duplicates that the standard MIDI input code, but I write the >bytes to MY buffer, and time-stamp each byte when it comes in. You really must write your midi interrupt handler in assembler. Fortunately this handler is pretty simple. The standard Atari interrupt handler is actually pretty good, but you can optimize it slightly. For an example of the source to the standard handler, see the Abacus Internals book. The default buffer is much too small (128 bytes, I think). With a good handler, a decent size buffer, and a good cable (most are crappy), you shouldn't lose any data. > This method allows application freedom, as MIDI input will happen in >the background. BUT I STILL LOSE DATA WHEN I MOVE THE MOUSE... This is true and it sucks big time! The problem here is that the keyboard/mouse ACIA and the midi ACIA interrupt at the same level to the MFP 68901. Also, the mouse packet parsing code is just too slow. If you blast the midi port at full speed and move the mouse, its possible that 2 midi characters will come in while you're parsing a mouse packet, and BOOM! you lost the first one, since the hardware only buffers one character. The midi handler cannot preempt the (slow) mouse handler, and this is a hardware architecture problem. The solution of course is to rewrite the mouse/keyboard handler, which is pretty difficult, especially if you want to maintain compatibility with the way the OS expects to find things. If you're writing a standalone sequencer, this really isn't a problem, but for joe average it's difficult. If you roll your own sequencer without the mouse handler, just _don't_move_ the_mouse_ (!) during critical times! (1/2 8^)) I hope this helps... Every profession sequencer writer has had to deal with this. -sam (sam_s@NeXT.com)
burris@highspl (David Burris) (02/07/91)
From article <1991Feb6.151810.986@daffy.cs.wisc.edu>, by carter@cat27.cs.wisc.edu (Gregory Carter): > > Well what do you know, finally someone asks a question up my alley! > John, I wrote some networking software for the midi port and ran into > the same problem, the Bcon calls are too slow to retrieve information fast > enough(In TOS 1.0 they are anyway, TOS 1.4/1.6 its a little better) from the > input buffer. Solution? In increase your buffer size to about 4K, for really > TAXING operations, increase to 16K. I use an 8K buffer and don't have any > problems at all. Real time . -- ================================================================ David Burris Aurora,Il. burris@highspl { att | linac }!highspl!burris ================================================================ our code is executed. If the assembly routine saves ALL registers, it can push the MIDI byte onto the stack and jsr directly to a C routine. If you allocate a lot of local variables or nest function calls too deeply, you might want to point the stack at some space allocated in your assembly routine. I would not be too surprised that you could generate enough interrupts of higher priority that a MIDI interrupt might be serviced after the next byte arrives. I haven't experienced this problem but I haven't really TRIED to produce it either. Be careful about using registers you haven't saved in your assembly routine. At the time the interrupt occurs, you have NO idea what might be in the registers. I kept having the temptation to believe that I had access to the scratch registers of the C compiler. -- ================================================================ David Burris Aurora,Il. burris@highspl { att | linac }!highspl!burris ================================================================