Conference 7.286::atarist

I was able to read a full sysex dump from the D5 without dropping any
data by using the Iorec() xbios routine to create a midi input buffer
that was larger than the entire length of the sysex dump, and so long
as the mouse was not moving when I did it.

I always wanted to write a patch editor/librarian for the D5, because I
couldn't find any PD or commercial ones that really understood the D5,
but never got any further than parsing the dump into a data structure. 
So, I have all the data in a nice, neat organization, but no functions
to display or edit it.  I would be more than happy to give you the
work-in-progress if you wanted to borrow from it.  I've stopped working
on it in order to build a soft midi effects box. (Which is coming along
nicely by the way.)

    	I have written an almost complete timbre editor/librarian for the
    D5.I got most of it working but then moved on to other things.
    	I used STOS,because I wanted graphics such as slider bars to
    represent controls.
    	This and the midi input is very easy to do with stos,ie
    	INPUT(channel,count).
    I tried first with gfa basic but had the same problem as you.I read
    somewhere it is because the midi buffer is to short.
    
    	Let me know if you are interested in this solution.
    
    	Brian.
                                    

    I've tried many ways to avoid overflow, and seem to be able to 
    get all the data, BUT NOT WHEN THE MOUSE IF MOVING.  If anyone
    has a solution/workaround PLEASE post it!
    
    Thanks!
    
    _John_

Thanks for the quick replies!

I'll try Iorec() and see how I get on. Thanks for the offer of your code, but
since I'm doing this for fun anyway I'd like to see if I can get it running
myself first! I'm quite new to ST programming but I have some good books on the
various gemdos and bios calls. I just need a bit of help when I get stuck!
I'll let you know how I get on.

Thanks again,
Tony.
    

    well....
    
    I got the tone data transferred intact using Iorec to set up a 1k
    buffer. However, for anyone else trying this, another gotcha is the
    fact that the D5 transmits midi active sensing codes a couple of times
    every second. This means that all the while the D5 and ST are powered
    up and connected, the ST's midi buffer is gradually filling up with Hex
    FE's. The way I got it to work reliably in the end was to empty the
    ring buffer by resetting the head and tail pointers just prior to dumping
    the tone, then filtering out any active sensing bytes from the data
    returned from bconin. Note that the buffer must be emptied every time
    round before transmitting new data, as even 1k soon fills up with the
    active sense data. Unfortunately there appears to be no way to defeat
    this D5 feature.
    
    In my case things were getting even more confused as I had a hardware
    sequencer on-line as well, which was sending active sense bytes AND
    midi clock information all the time!!
    
    Tony             

    Hi,
    
    	Be aware that some MIDI devices (sequencers, drum machines) will
    	transmit F8 continuosly (24 per beat)...
    
    _John_
    

    Ok... still working on this project!
    
    I've now got over the fact that the D5 expects addresses in SEVEN BIT
    HEX (it took a lot of head scratching before I finally noticed the tiny
    print in the manual!) but there's also another funny.
    
    The manual says that the internal tone data starts from address 80000h
    and each one is 200h bytes long. This works fine up to tone #32, but
    trying to retrieve #33 is really difficult. If you ask the D5 to dump 
    from 84000h then the data returned is NOT the start of a tone.
    Alternatively if you ask it for 83f75h then you get about 10 bytes of
    zero's then the tone data. I can accomodate this in my program but it's
    weird behaviour. Also the tones beyond #33 do not lie at the addresses
    quoted in the manual (and the addresses you would expect if you work
    out the offset in 7-bit hex). I found them eventually by trial and
    error.
    
    Any ideas??
    
    Tony

You are beyond me now.

BTW, it has to be 7-bit, the 8th bit marks the beginning of a command.

    No problem, thanks for your help. My program's working OK, it's just
    taken a few hours of fiddling around! 
    
	Tony

As soon as it does anything useful with the D5, I'd like to play with a
copy.  I have avoiding changing ANY patches, because I dont't have a way
of storing the original versions.

    Sure, I'll let you know when it's in a fit state! One thing is, once I
    found out how to use IOREC I recoded in GFA Basic as the screen
    formatting was getting toooo difficult in assembler. GFA has a handy set of
    calls BIOS() XBIOS() and GEMDOS() which let you access the system
    services directly, just as you would in C. 
    
    BTW, I've got a couple of D5 system dumps stored on my sequencer, so I
    can just reload after fiddling around, otherwise I wouldn't be doing
    this either!!
    
    Tony

    I tried over the weekend to get STOS to read and write to the Midi
    ports without success. Could you please post and example of code that
    you use to read and write with STOS. I have found the Open statement
    and managed to get some DATA in with the PORT command. The STOS manual
    is hopeless on peripheral I/O.
    
    Thanks in advance 
    
    Kev