m204help@cca.CCA.COM (Keith Hedger) (03/18/87)
I am trying to read data from the midi in port on the 520 ST and am having a problem. My program is written in MEGAMAX C and basically grabs midi data a byte at a time and stuffs it into an array...when the array reaches a length of 78 it is displayed on the screen and a new string starts getting written. My problem is that I hook up a sequencer to my ST and start it putting out midi data and start running my program. My program always displays 4 or 5 lines of midi data then exits the program. (In other words the sequencer is still running). If I stop the sequencer and run the program again, it typically puts out another 4 or 5 lines of midi data then stops. I run it again and the port is clear. My program is basically built with a big 'while' loop which says 'while data is at the midi in port do blah blah blah'. I have seen some messages from the 'bix' section of Byte where people were saying that they had had the same kind of problem, and that the buffer that handles incoming midi data is too small....they allocated their own buffer large enough to handle the data. My question is: If the buffer is filling, why would having my program read from it and stuff the data into a bigger buffer, work any better than reading data from it and putting it into strings to be output ? Is putting the data in strings to be output that much slower than moving the data into an internal buffer ???? I would appreciate any suggestions any of you MIDI hackers out there can give me. thanx, keith hedger '
rgoodman@cit-vax.Caltech.Edu (Ron Carl Goodman) (03/20/87)
In article <14085@cca.CCA.COM> you write: >... >grabs midi data a byte at a time and stuffs it into an array...when the >array reaches a length of 78 it is displayed on the screen and a new >string starts getting written. My problem is that I hook up a sequencer >to my ST and start it putting out midi data and start running my program. >My program always displays 4 or 5 lines of midi data then exits the program. >My program is basically built with a big 'while' loop which says >'while data is at the midi in port do blah blah blah'. The problem is really that your ST is a fast computer! When your sequencer is plopping out data, your ST reads it in. At first, before your program is going, the data is stored in the 128 byte midi buffer. As you read the data, more is being placed in the buffer, but the sequencer does not spew out data as fast as the ST reads the data. So your buffer is eventually depleted. When the ST catches up (based on when you ran the program in relation to turning on the sequencer) your ST will make a request for data and there will be none waiting. A fraction of a second later, some will be waiting, but its too late... your while loop has fallen through. One solution is to use something that checks the port N times before deciding that no more data is truly there (to be sure that no more is coming). N can be found experimentally. 300 is plenty. This kind of method is sort of icky, because N may not work when this program is run on a different computer. Another solution is to call a system timer with a delay of like 1/10 of a second and check again before determining no data is left. By the way, you might wonder how this method works, since the time between two notes could actually be far more than 1/10th of a second. Sequencers put out timing signals as part of the MIDI code (I think 247) at a constant rate to solve that problem. Unfortunately, there is no standard END_OF_ SEQUENCE marker. Ron Goodman -- rgoodman@cit-vax.caltech.edu _______ _________ _________ | rgoodman@cit-vax.bitnet / \#/ \#/ | Pasadena rgoodman@cit-vax.uucp |alifornia |nstitute |echnology | California \_______ ___/#\___ of | | U. S. A.
burris@ihuxz.UUCP (03/20/87)
In article <14085@cca.CCA.COM>, m204help@cca.CCA.COM (Keith Hedger) writes: > > I am trying to read data from the midi in port on the 520 ST and > am having a problem... > ...when the > array reaches a length of 78 it is displayed on the screen and a new > string starts getting written... You do not have enough real time to be doing printf's and/or other screen output if the MIDI data is coming in at near the MIDI baud rate. The 520ST does use a circular FIFO buffer algorithm and you MUST unload the data into your private buffer fast enough to insure that there is no overflow. Disk I/O is completely out of the question! MIDI data MUST be stored in memory until completion then stored. I have solved the real-time printing problem in the hopes of real-time graphical note representation by driving a MIDI 1.0 protocol handler via the MIDI port interrupt and using my own interrupt code instead of ATARI's. This frees the processor to do other tasks between MIDI bytes while insuring that notes don't get missed. Dave Burris ihnp4!ihuxz!burris
rgoodman@cit-vax.UUCP (03/21/87)
In article <1932@ihuxz.ATT.COM> burris@ihuxz.ATT.COM (Burris) writes: >In article <14085@cca.CCA.COM>, m204help@cca.CCA.COM (Keith Hedger) writes: >> >> I am trying to read data from the midi in port on the 520 ST and >> am having a problem... > >You do not have enough real time to be doing printf's and/or other screen >output if the MIDI data is coming in at near the MIDI baud rate. I don't think you normally have to concern yourself with that since sequenced MIDI data does not come in anywhere near the MIDI baud rate. Each second, MIDI theoretically can transmit almost 4K, but in reality, it transmits less than a hundred bytes per second generally. If you're having a problem because your sequencer adds timing marks that increase the bytes/sec (still nowhere near 4K/sec) then simply ignore those bytes. I have displayed MIDI data using C. True, if you are displaying 100 numbers/sec you are at about the limit, but that is not what caused Keith's original problem of his program ending before the data was all sent. That was caused by the fact that his program thought he was out of data because he read it too fast. Receiving MIDI data itself takes a small percentage of the processors time unless you are transmitting special data (e.g. with a sampling synthesizer you might transmit the waveform data). Ron Goodman -- rgoodman@cit-vax.caltech.edu _______ _________ _________ | rgoodman@cit-vax.bitnet / \#/ \#/ | Pasadena rgoodman@cit-vax.uucp |alifornia |nstitute |echnology | California \_______ ___/#\___ of | | U. S. A.