Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!caen!spool.mu.edu!munnari.oz.au!yoyo.aarnet.edu.au!sirius.ucs.adelaide.edu.au!mbaker
From: mbaker@ucs.adelaide.edu.au (Matthew Baker)
Newsgroups: comp.sys.atari.st.tech
Subject: Re: RECORDING MIDI DATA ON THE ATARI ST (while allowing mouse movement)
Message-ID: <3580@sirius.ucs.adelaide.edu.au>
Date: 6 Jun 91 10:44:21 GMT
Article-I.D.: sirius.3580
References: <5133@ryn.mro4.dec.com>
Organization: Information Technology Division, The University of Adelaide, AUSTRALIA
Lines: 32

From article <5133@ryn.mro4.dec.com>, by miskinis@aidev.enet.dec.com (John Miskinis):
> 
> Has anyone come up with a mechanism to record MIDI data at high speeds,
> and allow mouse movement/operation?  I'm getting all the data, and
> timestamping it OK, but I will always get corrupted data when I start
> moving the mouse.  I bring this up again and again, in the hope that
> someone new to the conference will see it and post a routine that solves
> this problem.  I know it can be done, as the best sequencers for the ST
> appear to do it perfectly...

I don't know about posting any code... 
Your problem is simply that moving the mouse generates _lots_ of data. 

There are several ways of getting around this. One, tell the IKBD to shut
up about the mouse, and then, when you know you have the time, ask it for a 
position update. You can also use IKBD fn $13 to shut up the keyboard for a
short period of time, and it will attempt to buffer mouse movement...
 
-all this, of course, means that you have to do your own mouse handling.
No more Gem. This may be OK.  Another alternative is to rewrite the mouse
interrupt handler, assuming you can find it, and decipher what it is doing.
Note that this is a _real_bad_idea_ and should only be considered in 
utter desperation.

> A shot in the dark from someone who want's to provide the world's
> musicians with a software system that make the Atari ST shine,
> 
> _John_

I wish you luck, John. I hope that all works out ok.

Matthew