Conference napalm::commusic_v1

    Seems to me you've run into the classic problem that separates the
    pros from the garage hackers.  Don't know about the ST, but seems
    to me that some machines vary in timing because the processor has
    to share a bus with other stuff (like video processors) or they
    may have occasional wait states because of memories having to catch
    up.  One way the pros get around this is to use an external timer
    with a register that is readable.  Instead of relying on software
    wait statements, they poll the external timer and base driver routines
    on that.  Since you're writing in C, you already have the advantage
    of writing in something that is close to Assembler and can probably
    write driver routines that are comparable in speed.  Since the baud
    rate of MIDI is around 30 kHz or so, you'll need to poll the external
    timer at at least a 60 kHz rate to preserve the baud rate.  If you
    don't have an external timer (I'm not familiar with ST's) you may
    have to do backflips to get accurate timing.  This may mean getting
    down to the Assembler level and counting machine states, etc. to
    set up very accurate timing loops.  In the end, you may find it
    less frustrating to shell out $50 for somebody else's software.
    
    Steve_who_loves_his_QX5

    Possibly your problem is more basic than what is described in .1.
    MIDI messages come from your device as you play the device.  It
    is the responsibility of the sequencer to keep track of how much
    time has elapsed between messages, and to wait that same length
    of time when playing back the messages.
    
    Here is a simple way to do this: store each received MIDI message
    in a variable-length string which appears as the last component
    of a record.  Also in the record is a delta-time byte which records
    units of 5 milliseconds since the last MIDI message.  That will
    let you represent up to about 1 1/4 seconds between messages.  To
    record longer delays, just allocate records with 0-length MIDI messages
    and maximum time values.
    
    Other fields in the record would be used to link the records together
    in time-order.
    
    Doing this requires that you use more memory (perhaps 12 bytes
    additional per MIDI message) but that shouldn't be a problem on
    a large-memory machine like the Atari 1040 ST.  It also requires
    that you parse the serial data stream to recognize MIDI message
    boundaries.  That isn't very difficult if you have the MIDI
    specification.  All messages are fixed-length depending on their
    first byte except System Exclusive, which is terminated by hex F7.
    
    Good luck.  Please let us know how it comes out.
        John Sauter

Good input so far.  I would like to add to .1 that if you are able to call
the operating system (I'm not familiar with the ST) via system calls, use
a system call for timing purposes.  If you are unable to call the operating
system for timing info, then you have to poll the interrupt driven timer
(I'm sure the ST has one) when a byte is recieved.  You may also want to
turn off all other interrupts that may stall the processor (of course you
will need the UART interrupts for the serial port to recieve and transmit
MIDI).

I recommend doing what you're doing to toy around, but I think it's worth
the $100 - $150 for a good canned sequencer program that has already been
debugged and has nice graphics.  There is plenty of sequencer information
buried in this conference.

Good luck,

Todd.

    
    one thing. .1 mentioned keeping up with midi data at twice
    the midi "frequency". This is not sampling, where the information
    desired is in the 'waveform' of midi events vs. time, which would
    invoke the Nyquist theorum (twice the highest freq component samples).
    
     Keeping up simply  means being able to get a midi byte from the input
    port, processing it, and then being ready to do the next. There
    is 100us between bytes in a *continuous* midi data stream. Do you
    have time? Depends on the hardware, software, and what you want
    to do....
      
    ron
    

    Hmm.  Well, you've entered the realm of fun an frustration.
    
    First, I have not been able to find a good, economically priced
    sequencer for the ST, but I have not checked the market in around 2
    months. Most of the lower priced ones don't give you jack for control.
    That is, they are like n-track recorders, and that's it.  No editing,
    and no looping.  Useless, in my opinion.  The nice ones seems to cost
    upwards of $300 dollars.
    
    So if you are really serious about writing your own (I am, but I
    haven't gotten up to full steam yet), then I can offer a few
    suggestions:
    
    1)  On the ST, a good timer is hard to find.  I haven't been able to
    find a nice memory location that you can simply peek.  The ST has four
    programmable timers, and one of them (timer A) is reserved for user
    use, so I plan use this guy. 
    
    2) Some music expert found that the maximum bandwidth of human
    performance gestures is ~200Hz.  This means that in order to be fully
    responsive, you must be able to time-stamp the info you get from the
    MIDI port to 200Hz granularity, or 5ms (is this were you got this
    number, John?).  Also you must be able to send messages accurately at
    this rate.  This doesn't mean that you only have to deal with 200
    bytes/sec, however, since most standard MIDI messages corresponding
    to a performance gesture are 3 bytes.
    
    (We admit that, while dumping the entire voice memory of a keyboard
    certainly could be considered a performance gesture, you won't be
    receiving 200 of these ~8K byte messages per second).
    
    So that's some of what you're up against.  If you need more help
    (or want to share revelations), let me know.
    
    Steph

Dr. T has a sequencer available for the ST.  If it is anything like the
C64 version, it is both powerful and cheap.  I would guess in the $150 range.

Todd.

PS: Always keep an eye on the used market.  The nice thing about software
is that it is as good used as it is new.  Nothing to wear out (except the
media itself, and that's hardware %^} ).

    re: .5--yes, the 5 milliseconds was based on gesture speed.  However,
    it was independently derived--I did the "study" myself, and I am
    certainly not a ``music expert''.
        John Sauter

    Dr. T is resonable.  List price is $195.  There is a review in this
    months MCS.
    
    Personally I'd rather buy gear with that money and write my own.  I
    think $70 is my ``buy-wait'' threshold for such a program, and I have a
    feeling that will be broken soon by a program of Dr. T calibre.
    (damn it, it will, if I have to break it myself.) 
    
    Steph (the parsimonious electronics addict)

    Hi Guys,
    
    	Anyone out there have a problem with an ATARI ST losing bytes
    during a recording?  I get a duplicate byte (the interrupt triggered),
    but the byte I get is a copy of the last one...
    
    Thanks in advance,
    
    _John_  (Who get's a problem like this approx. 1 in 10,000 bytes when
    	     sending data to the ST rather quickly)
    
    

Did you check the 6850's status register before reading the data?
I suppose you'd have to, because there are other things on the same interrupt.

    Hi Jeff,
    
    	WOW a reply!  Thanls! I believe I do...  I basically copied the same
    assembler code as was in the BIOS listings in the Abacus Internals book.
    I modified 
    it however, so that the data was not put in the regular buffer, it goes
    to my area.  In addition, I store the current value of a PULSE and BEAT
    that is asscoaited with the byte.  This is reduntant for "packets" of
    data, but at this point it suits (more than) the purpose...  I'm also
    wondering if TIMER A interrupts have something to do with it...
    
    	I'd rather not post my source, but I'll be happy to give it to
    you privately...  
    
    I'll doublecheck the 6850 status check...  Also, I had this problem 
    BEFORE, when I used BCONIN, with B-something-STAT in a polling loop.
    
    I figured if I went to an "interrupt driven" routine, I'd get over
    the problem...
    
    _John_
    
    

Have you tried other ST's?  Is there a chance I could reproduce the
problem in my own lab?  I have a few ST's and a D5 to work with.  Of
course, it would have to wait until after WAACE - I still have a lot to
do between now and Saturday.

    Hi Jeff,
    
    	NO, actually I haven't.  BUT I've tried other sequencers on my
    system...  I'll give my code to a couple of my friends, and see if
    they get the same results...
    	
    	Over the weekend, I put some code in, to check the status of the 
    6850.  Also, I replaces the MIDI-IN vector, with IKBDVEC, such that
    my routine is executed when a level 6 interrupt is generated, and the
    system code already has "qualified" the interrupt, and found it to
    be a MIDI-IN.  
    
    	So (in theory) there should be a byte there waiting to be read.
    
    	The code I added displays whether there's REALLY data in the ACIA,
    and also if there's an overrun error.
    
    	It seems that I get the data PERFECTLY, but as soon as I move the
    mouse during input, I get lot's of EMPTY conditions (no data in ACIA,
    reflected by the "full" bit clear), and a FEW overruns..
    
    	I wonder if I'll have to rewrite the entire level 6 interrupt
    handler, to check the MIDI ACIA, and then check the mouse and keyboard.
    
    I WANT ACCURACY IN MY DATA STREAM!!!!!
    
    _John_
    
    P.S.  Thanks for your reply/concern!