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.)