Playing sound
Volume Number: 7
Issue Number: 1
Column Tag: XCMD Corner
Playing With Sound
By Donald Koscheka, Contributing Editor
Note: Source code files accompanying article are located on MacTech CD-ROM orsource code disks.
The Importance of XCMDs
One of the questions that is raised by Hypercard 2.0’s new XCMD interface is,
“How important are XCMDs to the vitality of the Macintosh?”. One cannot imagine that
XCMDs would be very important at all so it would be useful to the xcmd programmer to
ponder the future of xcmds in the Macintosh programming world.
After studying Hypercard 2.0 in great detail, I’ve concluded that XCMDs are very
important to the success of this product and that Apple Computer, Inc. is acknowledging
this by providing more services to the XCMD programmer such as windoids and script
manipulation capability. But another event in the small computer world lends even
more credence to XCMD as programming art. That event is quietly taking over the
MS-DOS world as Microsoft successfully evangelizes the concept of Dynamic Link
Libraries, or DLLs.
If you’re not a PC programmer (and who can afford not to be), then you may not
know that DLLs are code modules that are written in such a way as to be loadable and
thus callable at any time. DLLs are code segments that have a standard programming
interface associated with them. In effect, DLLs allow you to build re-usable code
modules that in theory can be used in any application. Well, if every application had
such an interface on the Mac, let’s call it XCmdPtr, then xcmds would serve the same
purpose -- the ability to call xcmds from any program that runs on the mac. Without a
lot of induction, one can come to the conclusion that if xcmds can give you this type of
capability on the Mac, then they are indeed important, at least at the conceptual level.
If xcmds become callable from any application then they become an integral part
of the future of the Macintosh. It is not unimaginable to believe that someday you will
flesh-out your application with some sort of screen generator and then build a set of
xcmds to implement the application-specific code. I find it impossible to believe that
this effective approach to programming won’t become the norm for all programmers in
the future. In fact, Michael Swain suggests exactly this approach for PC programmers
using ToolBook ( “Dr. Dobbs Journal”, November, 1990). When I read this column,
my eyes popped out of my head. Mr. Swain’s concept of marrying rapid prototyping with
rapid code development via DLL’s is exactly what we’ve been doing with Hypercard for
the last three years. Any Windows developer that takes his advice will wonder what all
the fuss was about; Windows will appear to be an easy and natural development
environment.
So now I can rest easy. I am convinced that the XCMD approach to programming
will prevail over time. It’s working for me. By forcing me to avoid globals and to think
modularly, XCMDs have allowed me to write code that is re-usable in a wide-variety of
applications. Each time I write an XCMD, I create a piece of code that I not only know I
will use again but that I can comfortably extract from Hypercard without worrying
about breaking it. That is the programmer’s holy grail and that is why XCMDs not only
have a future, they are the future.
Playsound
Several months ago, I got a call from Bill Leitman, a fellow Mac developer in the
New York area. He was working with a small film company in Brooklyn that needed an
xcmd that played a portion of a sound resource. Bill’s approach was quite reasonable,
he took a piece of code that he knew to be working from another application and dropped
it into an xcmd. Lo and behold, it didn’t work. He called me in desperation to see if
there was anything that I knew about xcmds that was causing his problem. To no avail,
I also tried to get the sound manager to work from within an xcmd but after hours of
head scratching and staring at TMON windows, I came to the conclusion that Hypercard
just wasn’t going to let me use the sound manager.