Conference napalm::commusic_v1

    Tom,
    
        The topic of RS-232 to MIDI was discussed in note 877. Edd put up
    some stuff about building an interface for the Ensoniq Mirage.
    Unfortunately, the design depended upon the Mirage's ability to set its
    MIDI baud rate. How's THAT for a dynamic parameter?! There are also other
    references to similar notes.
    
        SCSI to MIDI? Sounds neat. I'm sure SOMEWHERE in the industry,
    somebody has one of these. You sure JLCooper hasn't built one yet? If
    not, build one yourself. You'll probably make a bundle. 
    
    dp

I don't know if this might help with what you are trying to do but the 
Ensoniq EPS has a SCSI option. It is used to access a standard SCSI disk.
The EPS will handle Sysex data, and I *think* you can transfer the Sysex data 
to either the internal 3.5 inch disk or the SCSI drive. 
	Would this be of any use in your intended application?

  I already have a line on some serial to MIDI interfaces, I'm more interested
  in SCSI.  I have an EPS and am also pursueing trying out one of our SCSI
  disks on it, but that's another project.

  Right now I'm looking for SCSI/MIDI for our workstations, either VAX or RISC.
  VAX/VMS supports open SCSI, and I know of several 3rd party deviced such
  as CD-ROMs and 9-track tapes that have worked 1st try 100%!.  If a SCSI/MIDI
  exists, I'm not sure what it would have for built-in "driver" support, if
  any, as these other devices do.  In which case, much more work would need
  to be done.

  I'm not a hardware engineer, so building my own is not in my realm of
  possibility at this point.  However, I suppose I could pay someone to build
  it for me, then market it, and maybe still make a lot of $$!

  I don't know, as reply .1 points out, SOMEWHERE out there this must exist,
  either commercial or a hacked version from someone, which is my reason for 
  posting this note.  Anyone know where?

-Tom

  
  

    Why woudl you want a SCSI  <-> MIDI interface?  I don't see any value
    in it at all.  Curious ...

+b

    To get around the limitation in the capability of most computers to
    run their serial ports at a high speed, or an odd speed (MIDIs rate
    is not standard for communication), or on multiple MIDI busses
    simultaneously.
    
    DMA assist on SCSI ports is not unusual (except on Macintoshes :(),
    and it can easily handle the aggregate data of many MIDI busses at
    once.
    
    The right way to do a driver for such a thing is to take a careful
    look at Apple's "Midi Manager", which provides multiple time-stamped
    virtual channels even over a single MIDI buss, and provides a
    centralized clock source.
    
    Today's hot PCs and workstations can easily drive multiple busses
    in performance.

As long is money is no object, my first cut at this would be to connect
an Atari ST with an ICD DMA to SCSI adaptor, and write custom software
for the ST that would use the SCSI adaptor as a slave device on the
SCSI bus, instead of it's usual mode as master, and move the bits out
the Midi port when they arrive.  Likewise for the incoming stream. 
Actually, my FIRST cut would be to use Dave Conroy's 5380-based host
adaptor, because I KNOW that it can be used in slave mode, whereas I'm
not as sure about the ICD.

Blast the wole thing into a ROM cartridge and remove the keyboard, and
you have a stand-alone box that does what you want.  Use a cheap second
hand '520, and the resulting device shouldn't cost more than $500 (and
about 100 hours of hard labor).  You might want a more substantial
machine to actually write and test the software.

The real question I would have about this is timing.  On midi, timing is
determined implicitly by the space between bytes on the wire.  With
SCSI, you would naturally want to send data in larger clumps that one
byte, so to get proper timing, you would want to imbed timing
information into the packet itself.  I suspect that there is already
some sort of standard for this, but my first cut at it would be to send
a data stream where every other byte was a byte of delay information.

    At the price a SCSI MIDI box could sell for, you might as well put a
    SMPTE/MTC decoder in the box and have all clock resolution done there.
    This way messages from the box to the computer could carry SMPTE times
    at which they were received or are intended to go out.  Each message
    has to carry an additional Buss number anyway.  (To justify the price a
    SCSI adaptor should have something like 8 busses.)
    
    This relieves the computer of having to do very precise timing.  MTC
    messages can arrive at a rather furious rate, and having the box deal
    with them might make some things easier.  (2 bytes per message, 4
    messages per frame, 30 frames per second = 240 bytes per second.  Like
    feeding 2400 baud into the computer in a steady stream, no control-flow
    allowed.  Some operating systems whose names start with "V" have
    trouble with things like this.)

  Thanks for the info so far.  The way this all started thus far was something
  like this...  I'm working on a large demo project for DEC that show's off
  PC integration, including MS-DOS, OS/2, Macintosh, VMS, AND Ultrix.
  To do this we're making use of PC/Mac based sequencers, scoring packages,
  and of course MIDI.  (as well as PCSA for VMS and Ultrix for the actual
  integration itself)

  When we first started presenting this for approval as a project for funding,
  etc, and again when have been presenting at meetings for PC Expo, DECworld,
  etc.  The same question kept coming up:  "How come we can't do this stuff on
  our Workstations?!"  Instead they're just sitting there as invisible file/
  applications servers not doing anything.  (of course they are the cornerstone
  as to why this all works, but you just can't "see" it)

  So I set out to investigate getting something to MIDIfy one of our
  workstations.  I knew of the serial converters back from the days of people
  MIDIfying their Pros, but all I heard out of this were problems.  I know of
  a couple other areas within DEC where people are playing with MIDI on the
  workstation.  We're working with someone out in WSL now who is designing
  something for the new DECstation 5000.  From what I hear, they have something
  working that makes use of a Mac MIDI interface.

  The guy I share my office with is more of a hardware technician and has
  driven several SCSI projects and suggested or rather questioned about SCSI 
  for the interface.  This peaked my curiousity and so I set off to investigate
  that further, and so....  here we are!  So that's the story.

  But it seems like there's some definite possibilities here, I like the idea
  of the SMPTE/MTC timing, multiple busses, etc.  I got some juices flowing.
  Any more ideas/suggestions?

-Tom

	I understand your motivation, but going SCSI to MIDI sure seems
	like a tough way to go...  Are you sure you don't want to try one
	of of those KEE serial-to-MIDI converters?  You might be
	surprised by what a priority 16 process talking directly to the
	serial port could do!  Alternatively, something like a KMV1A
	could be set up to do an MPU-401 emulation...

    It depends on whether this is a one-shot or a new product.  I was
    talking about a product.  For a one-shot, go with the serial interface.
    
    But for a product, consider that DEC Ws's are not cheap, and everything
    we sell for them has to be positioned at the high end.  You wouldn't
    want DECs "MIDI interface" to be a wimpy one-buss arrangement when dual
    busses with integrated sync are the norm for PCs in professional
    studios.  And we have to be *better* than them.  And of course we have
    to talk sequencer vendors into writing stuff for our platform.
    
    (And pros are the only people likely to buy a DEC WS for MIDI anyway.)
    
    Need standards here too.  Via the IMA people like DEC and Apple and
    Opcode should get together to decide on what such interfaces should
    look like so that the software people can develop for multiple
    platforms.  DEC really needs this, since in any case DECs share of the
    music computer market is going to be vanishingly small even WITH the
    software.

How about putting the MIDI on the Ethernet?

I could easily imagine a modified DECserver that provided up to 8 midi
ports to any (set of) VAX workstations on the same ethernet.  (I can
imagine this more easily that I'm willing to say in a public
conference.)

In fact, you could just string one strand of thin-wire across your
studio, stopping behind each rack of equipment to tap the wire and
generate 8 midi ports.

    Kind of expensive.  (At keast if DEC built it.)  And ethernet
    connections are nowhere near as common as SCSI ports.  Working off SCSI
    means we might even sell some of them for use on machines other than
    those made by DEC.

> In fact, you could just string one strand of thin-wire across your
> studio, stopping behind each rack of equipment to tap the wire
    
    There's a set of products and future products available from 
    "Lone Wolf Systems" (I think) called "MediaLink" (I think)
    that is sortof "MIDI done like the ethernet".
    
    It is indeed VERY expensive right now.
    
    We've talked about it a bit in this conference somewhere.  I'm
    extremely excited about it (it would solve a good deal of problems
    for me), but it's a long way from affordable at this point in time.
    
    If they find a way to make it less expensive, I'm certainly it will
    be the "replacement" for MIDI (but a compatable replacement since
    it is built on MIDI).
    
    	db
    

    ...last I heard, the LoneWolf MediaLink systems were going about
    $2500 a pop for the "DEMPR" (for lack of a better term)...
    
    Edd

    Len must not be reading this note...
    
    There's a big problem with using Ethernet for MIDI. Not only is the
    cost prohibitive, but you have a design problem with CSMA/CD. What this
    means is that you cannot know reliably how long it will take a packet
    to be delivered. I think this was the principle design snag when NaC
    was talking about building a time server for ethernet.
    
    CSMA/CD means Carrier Sense Multiple Access with Collision Detect. The
    idea is that a station on the etherhose that wishes to transmit listens
    for the carrier (signifying all clear) and starts talking. If, after
    starting the transmission, the station discovers that someone else
    started talking at the same time (collision detection) the station
    stops transmitting, and checks for the carrier again after a random
    waiting time. 
    
    dp

    Yep -- best design it using Token Ring instead.
    
    Richard.

Yea, yea yea, but if you network consists of only one VAX workstation
and two or three MIDIserver devices, the retransmissions cause by
collisions using the LAT protocol will always be well within
"noticable" time.  I wouldn't try this on the MILL Ethernet, and DON'T
put a bridge between the VAX and the server, but it should work fine in
the limited case.

The more serious timing problem will be that LAT takes everything that
happens in 80ms and sends it out in one chunk.  You can adjust
parameters in LATCP and in the server to tighten this up a bit, at the
expense of some extra traffic on the ethernet, but it's unlikely to
actually get much below 40ms.  I think that, like with SCSI, you will
need to imbed timing information into the data stream, and have the
DECserver decode it in real-time.

Failing that, is there a defined "null" character that can be used
between Midi commands that will allow the timing to be done with the
baud rate clock?  Then the host could do it.

    I'm listening but none of this strikes me as practical enough to
    warrant more than just listening.
    
    The idea that Ethernet (CSMA/CD) is unreliable for time critical (or
    "real time") applications is a bogeyman that DIGITAL has been battling
    for a long time.  The time server didn't get built for other reasons;
    WANs are just as "unreliable" as Ethernets with respect to delays, and
    the time service architecture has to synchronize clocks over a WAN, and
    can easily cope with the sorts of "unpredictable" delays typical of
    reasonably loaded Ethernets.
    
    Actually, the notion of using SCSI or LAT as MIDI transports strikes me
    as utterly bizarre.
    
    len.
    

    SCSI isn't a transport; it is a connector.  The original problem was,
    given a computer with certain plugs on the back and no card slots
    inside, what is the best way to connect Midi cables.

    Sorry, SCSI may not be a transport but it's probably more than just a
    connector.  I'm not a disk jockey (sorry, I couldn't resist), but I'll
    bet there are expectations about what gets "said" when on what pins.
    That's functionally a protocol.
    
    len.
     

    Yeah, about like talking to a serial port chip, which is where MIDI
    usually connects on computers that aren't so brain-damaged that they
    won't take external data clock.  How one talks to a serial port chip
    is conceptually a protocol, but considering that the cable has a
    severe length limitation and the handshaking is so low-level ("here
    comes a byte"), I wouldn't carry it to far.  Command languages are
    protocols too by that definition.  (Don't tell the ISO)
    

If the problem at hand is connecting Midi to a PVAX, there is really
only one sane way, in my mind, to do it.  I *think* that the PVAX allws
you to split the baud rate on TTA2:.  If so, do it like this:

- Get two old-fashioned uarts, the ones that don't require a
microprocessor. 

- Connect their parallel ports together.  In to out and out to in.

- Clock one uart TX and RX at 32000 baud, and wire up the 5ma loop for
the Midi.

- Clock the other to TX at 38,400 baud, and RX at 19,200 baud, and
connect it to the VAX.

- SET TERM TTA2:/SPEED=(38400,19200)

By selecting the speeds in this way, the VAX can never overrun the
Midi, because the transmit speed is limited to something smaller, and
the Midi can never overrun the VAX hardware, for similar reasons.

(Of course, I just noticed VMS doesn't seem to support /SPEED=38400, but
I'll leave this message because it applies to solving the general serial
to Midi problem on other computers.)

	American National Standard for Information Systems (ANSI)

	Small Computer Systems Interface (SCSI)

	ANSI  X3.131-1986

	


	SCSI is a *standard*. Included in this standard  are the physical 
characteristics - connectors et al. Also included are the Logical 
Characteristics - protocol.

    SCSI stands for Small Computer System Interface
    not systems.
    (Digital News 4-30-90 Managers Briefing,"SCSI: It isn't just for
    storage anymore" Alan Radding.)
    ANSI= American National Standards Institute.
    John Lohmeyer is chairman of the ANSI SCSI-2 committee.
    SCSI can be pronounced "scuzzy."
    from the 5th para:
    "What exactly is SCSI?  Basically, it is an industry-standard,
    intelligent peripheral interface that "allows [the] connection of
    diverse, multiple-peripheral devices to one port, and it offers a high
    bus bandwith across the host and river interfaces."..
    From Charles Giorgetti, ws product marketing mgr at Digital:
    "The bottom line is that SCSI is an economical peripheral interface for
    our workstations".
    There is an ANSI committee on CAM, Common Access Method, for software
    commands over SCSI.
    There are eight addresses in SCSI, but usually 7 devices to one bus is
    usu. max.
    A "host adapter" is the interface between a computer and the SCSI bus.
    
    SCSI-2 is 68-wire (2 cables).  SCSI is 50-wire.
    	4 meters is a good limit on distance of a peripheral from a host.
    Differential scisi devices exist, and can go 25 meters from the host.
    Low end host adaptors can be $25, to $2500 at the high end.
    5 M-byte/second is a typical top limit.  Digital devices go around
    1.25Mbytes/sec.  SCSI-2 should certify this summer, with 10Mbyte/second
    (in 16-bit words), possible twice that.
    All this stuff was from the article.
    Tom