What is SMDI?
By Matt Isaacson
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?"
(To obtain a copy of the SMDI spec, contact Peavey Electronics
Corporation at [601] 483-5365.)
Matt Isaacson lives in San Francisco and has been a design
and development engineer with Sequential Circuits, Yamaha,
and Peavey over the last nine years.
|
|
 |
| |
|
