miskinis@aidev.enet.dec.com (John Miskinis) (06/06/91)
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 use a drum machine, at maximum tempo, playing a loop of a complex pattern for testing, and move the mouse in slow circles. It seems to generate a MIDI overrun about every ten seconds or so, on an intermittent basis. 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_
mbaker@ucs.adelaide.edu.au (Matthew Baker) (06/06/91)
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
csbrod@immd4.informatik.uni-erlangen.de (Claus Brod) (06/06/91)
mbaker@ucs.adelaide.edu.au (Matthew Baker) writes: >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... I tried this once, but failed big way. Turning the IKBD off for a moment didn't seem to turn off keyboard interrupts coming in. Turning it on again didn't always result in proper mouse handling afterwards. I also tried shutting off the keyboard interrupt via Jdisint(), but this led to even more trouble. I am _very_ interested in any hint to this problem. Anyone out there? Tnx! ---------------------------------------------------------------------- Claus Brod, Am Felsenkeller 2, Things. Take. Time. D-8772 Marktheidenfeld, Germany (Piet Hein) csbrod@medusa.informatik.uni-erlangen.de Claus_Brod@wue.maus.de ----------------------------------------------------------------------
nickolas@cpsc.ucalgary.ca (Nickolas Chondropoulos) (06/07/91)
Let me just say that IT CAN be done. Me and a friend have written code to do exactly what you ask for. There is only one problem ... the code is well ... proprietary. One hint though: Yes, you must write your own mouse AND MIDI interrupt handler AND you have no choice about the language, it must be assembler. Another hint: the desktop moves the mouse every two pixels not every one pixel. Oh yeah, when I say the code was proprietary that means it was done on a contract basis and we don't own the source. Nick.
geert@ahds.ahold.nl (Geert W.T. Jonkheer CCS/TS) (06/07/91)
In article <5133@ryn.mro4.dec.com>, miskinis@aidev.enet.dec.com (John Miskinis) writes: > 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 use a drum machine, at maximum tempo, playing a loop of a complex > pattern for testing, and move the mouse in slow circles. It seems to > generate a MIDI overrun about every ten seconds or so, on an > intermittent basis. > 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_ It seems to me that I am not the only one who is waiting for this answer. I have seen such a posting a few times. I think the only remedy to solve the problem is to rewrite the mouse handling routine, so that it works a lot faster. Unfortunately, I have no information of what the mouse handling routine must do, so that I can't rewrite this routine. John, I hope that you are using an interrupt routine for your music program, and that it's written in assembly. When it's not written in assembly, you must try it, it gives less more MIDI overruns. Also, the shorter the interrupt routine to handle the midi input, the less errors. As written in several atari docs, your interrupt routine must take less than 1 mS. I hope that someone out there has written a midi routine that works with the mouse. Hope to hear from it. Geert. ===================================================================== ============= G E E R T W . T . J O N K H E E R . ================ ======= A H O L D N . V . T H E N E T H E R L A N D S ======= ==================== geert@ccsds.ahold.nl ===========================