A standard method for transferring samples via SCSI is now
available. Will it catch on?

I'm not one to create acronyms for the sake of acronyms, but when
I tried to name a new data transfer method I developed, it made sense to
link it to another well-known member of the electronic music lexicon. So
yes, SMDI (pronounced "smi-dee"), an acronym for SCSI Musical Data
Interchange, rhymes with MIDI. However, it is not SCSI-MIDI, it is not
spelled SMIDI, and it is not pronounced "ess-MIDI." Those using these
spellings or pronunciations are in error and should be politely
corrected.

What exactly is SMDI? Simply put, SMDI is a method of using SCSI (the
Small Computer Systems Interface) to transfer information between samplers
and computers. SMDI has been characterized as "SCSI sample dump" because
it is based loosely on the familiar MIDI Sample Dump Standard (SDS). The
central aim of SMDI is to use the superior data transfer ability of SCSI
to serve the same purpose as SDS, that is, to send samples between any two
devices in a nonproprietary, commonly recognized format.

Life Before SMDI

The story of SMDI starts with the state of music equipment in its
absence. All previous methods of sample transfer have shortcomings that
grow more problematic as the state of digital audio improves. For example,
SDS has several flaws. It can't deal with stereo samples or samples longer
than two megawords, and it conveys a bare minimum of information about a
sample (names and pitch values not included) and none about the sampler
(such as its sample-number range). SDS also offers no tools for remote
management (e.g., a Delete command).

However, the greatest shortfall of SDS is that it uses MIDI and is
therefore glacially slow. MIDI was never meant to move large quantities of
data. It's a low-cost system for transmitting real-time event information,
working at a speed that just barely lets it do a competent job. On the
other hand, SCSI was born to move data. Even transfers over a low-cost
SCSI interface can easily be 100 to 300 times faster than an equivalent
MIDI transfer.

Thanks to its versatile design and wide acceptance as a standard by the
computer industry, SCSI is the interface of choice for sampler hard-disk
access. Its key advantages for the designer (and user) are standardization
and device-independence. SCSI disks handle the messy details of cylinders,
heads, buffers, and the like on the inside, and present a simple, standard
"virtual" device to the SCSI bus. SCSI driver software then deals with
this virtual device in a generic way. More importantly, a SCSI driver that
sets up a sampler for use with the whole range of SCSI disks ‹even those
not yet developed‹ must be created only once.

Samplers use the speed of their SCSI ports to upload and download
samples. However, the precise transfer methods for samplers are not
standardized over SCSI. Each sampler's implementation is usable only
through a coordinated effort by someone ‹usually a third-party software
company‹ working from the other end of the SCSI cable. Unlike SCSI disk
drivers, this effort must be duplicated for each sampler by each company
seeking to support it. A company may decide that the cost of this effort
isn't justified by the projected sales, or its programmers may be unable
to do it right away (perhaps because of other samplers that need
support).

Clearly, this is a losing situation for almost everyone involved, but
especially for users, who are resigned to seeing their sample libraries
remain "ghettoized" for lack of a usable interchange method. It also puts
a strain on manufacturers. Digidesign, one of the original heavyweights in
third-party sampler support, now puts its energies into SampleCell and no
longer supports samplers.

A few samples can read the floppy-disk formats of some competitors, but
this piecemeal approach to the problem involves a cumbersome transfer
method that is especially taxing for manufacturers to implement. It
certainly offers some utility, mainly as an "escape route" from one
sampler to another, but it does nothing to address the real problem or
facilitate new capabilities.

A Standard Is Born

A standard SCSI sample-transfer method would clearly be a boon to
all concerned. So why isn't there one? For starters, arriving at a
standard protocol is not trivial undertaking. SCSI is a big topic. It
covers a breadth of equipment in which musical instruments don't even rate
a mention. In the cloistered world of MIDI, every other unit on the line
is a MIDI device, but a SCSI cable normally plays host to devices that
don't know a sampler from a samovar.

In addition to the thorny technical problems, there is the question of
an appropriate forum in which to address the issue. It's far too narrow
for the American National Standards Institute (ANSI), the stewards of
SCSI. The focus of the MIDI Manufacturers Association (MMA) is MIDI; SCSI
is technically not part of their charter. However, unless a standard
emerges from an industry group charged with creating it, manufacturers may
be skeptical of its merit or may wait to see who else adopts it before
committing themselves.

Meanwhile, those companies that have forged ahead with proprietary
protocols are less inclined to feel that a standard would benefit them.
Some may be downright hostile at the suggestion that they scrap their work
to start over with a new method not of their own invention. In addition,
the desire for a standard protocol isn't universally shared. Companies
with large investments in sound libraries ‹and it is often the library
that makes or breaks a sampler‹ have reason to be wary of a feature that
helps users export samples en masse to other products.

How did SMDI evolve, then? Rather spontaneously, as it turns out. I
took a stab at it while developing the system software for the Peavey
DPM-SP. The SP is a low-cost sample-player without built-in sampling and,
at the time of its introduction, a rather limited factory sound library.
Clearly, in order for the DPM-SP to have any chance of success, the issue
of sample transfers had to be addressed. Users of other samplers would
want to move their personal libraries over to it, as would commercial
sound library suppliers. There wasn't time to crack three or four alien
floppy formats while also developing the native one for the DPM-SP. It
seemed that a well-supported SCSI transfer protocol was the best
prospect.

Rather than designing a product-specific protocol, I wanted to create a
generic one, hoping that this would make it easier to enlist the necessary
third-party support early on. In addition, I thought it might help break
the SCSI transfer logjam and trigger some other activity in this area. (No
harm in trying, anyway.) The powers-that-be at Peavey understood the
intent and gave the go-ahead to release SMDI into the public domain
without fees or royalties. This would encourage other product developers
facing the same problem to consider adopting the already-worked-out SMDI
method.

Such an attempt to parlay a unilateral creation into a standard is far
from unprecedented in industry. SCSI itself evolved from something called
SASI, the Shugart Associates System Interface. It's too soon to say
whether SMDI will become a universal standard, but among the companies
that have chosen to use it is Kurzweil in their K2000 synth/sampler.
That's an important first step. (For a current list of products supporting
SMDI, see the side bar "SMDIfied.")

What's In It For Me?

When (and if) it comes to your gear, SMDI can spare you lots of
waiting when shuttling your samples around; ditto for computer editing. In
addition, you don't need a DSP board in the computer just to audition
edits, because you can zip an edited sample quickly back into the
sampler.

If a new sampler were to join the SMDI club today, it would already be
supported by Alchemy, MAX, and SampleVision and enjoy the ability to
transfer samples directly to and from the K2000 and DPM-SP, with no
updates to any of those products and nary a phone call to their
manufacturers.

The adoption of a standard protocol might hasten the appearance of
previously impractical applications. For example, a centrally fed sampler
network could be designed in which all units receive their samples via
SMDI downloads from a common sample database accessed by a sophisticated
session manager. If you now use two or more different samplers and a
computer, your sample library may exist in different formats on as many
hard disks. If you're fortunate enough to have gigabytes of sounds,
redundant disks add up to real money. Wouldn't it be nice if your samplers
didn't need dedicated hard disks of their own?

SMDI also provides a method for transmission of MIDI messages. This
means that program information for each sampler could be maintained on the
same central disk as the sample database and sent along the same SCSI
cable (as SMDI MIDI SysEx) at the same blazing speed. (Don't throw those
MIDI cables away, though. Despite its data-moving prowess, SCSI is not a
good real-time event-transmission interface, and SMDI won't be replacing
MIDI anytime soon).

The same idea applies to CD-ROM sound libraries. With sound files in
the native format of the computer (e.g., AIFF), a single CD-ROM could
furnish samples to any SMDI sampler and include device-specific files that
organize these samples into sound banks for many different products, also
transmittable via SMDI.

The bottom line is this: The more you move samples around, and the
bigger they are, the more SMDI can help. As more manufacturers adopt SMDI,
the more it will help. The applications in this article are possible right
now, but they will become commonplace more quickly if SMDI (or something
like it) becomes a de facto standard in the music industry. If you'd like
to see that happen, make your voice heard. Manufacturers do listen,
especially when many voices are talking. Drop a letter or make a call to
your favorite sampler or software company and ask, "Where do you stand on
the SMDI question?"