I was talking with a movie producer the other day, and....But no. I was not talking with a movie producer the other day, and since that's the real point of the anecdote, I ought to get it right. I wanted to talk with a movie producer about a possible movie based on a book Paul Freiberger and I wrote back in 1984, and the producer wanted to talk with me, or with Paul, or with our agent. What I was actually doing, though, was engaging in endless e-mail and phone tag with Paul about who should talk with the producer. This was all quite necessary and appropriate, albeit annoying and tedious, because there were some subtle issues to clarify.
Agent stuff.
Rights and representation.
What a bore.
I'm glad I'm a writer and not a movie producer. Movie making is a very different sort of activity from writing. Movie making is a lot more complicated.
I'm with Gene Fowler on the process of writing. "Writing is easy," Fowler once said. "All you do is stare at a blank sheet of paper until drops of blood form on your forehead."
Making a movie, on the other hand, requires that you beg, coax, nag, threaten, and insult other people until drops of blood appear on their heads. At least that's my understanding. Not, I hasten to add, based on my interaction with the aforementioned producer, since, as I mentioned, I haven't actually interacted with him yet. I'm still looking forward to that.
All of which has-what, exactly?-to do with programming paradigms? Well, if you will grant me the point, which I've made here at least once, that developing a simple utility to perform some straightforward task is, in many ways, analogous to writing an article, then we have three legs of an analogy that does indeed lead us right into one of the more challenging and interesting programming paradigms today. The analogy looks like this: Writing an article is to developing a utility as producing a movie is to-what? Right, developing for multimedia. Which is, by an odd coincidence, the subject of this month's column.
Paradigm shifts are mostly about defining the problems to be solved. It should be easy to state the multimedia-development problem: integrating diverse media, like audio, video, graphics and text, into one multimedia product or production. By accepted definition, something that solves this problem is called a multimedia-authoring tool. Since there is no shortage of multimedia-authoring tools, this particular problem is solved reeeeeal good, right?
Not quite.
In fact, the plethora of mooted solutions may be indicative of a dearth of assimilation. Or, to extract that thought from the elongated-yellow-fruit school of writing in which it has been unwillingly enrolled: If you give your users four ways to solve a problem, it probably means that you don't know what the problem is.
(Two pedantic asides that would be hidden under hypertext links if this sheet of paper were smarter: First, the elongated-yellow-fruit school of writing was named in 1954 by journalist Charles W. Morton, who came across the defining instance of it in a story that came into the city room of the Boston Evening Transcript, a story "about some fugitive monkeys and the efforts of police to recapture them by using bananas as bait." Second, the non-elongated-yellow-fruit version of the thought is a paraphrase of a pithier quip that I couldn't lay my hands on by Jef Raskin, that erstwhile journalist and computer designer of the squat-red-fruit school of design.)
Giving the typical user four ways to solve a problem may be evidence of confusion on the part of the developer, but developers themselves may very well want four different ways to solve a problem, since the first three may prove impractical in a given context. Nevertheless, the really fundamental differences in approaches of the various multimedia-authoring tools suggest that nobody has yet nailed down exactly what the problem is. And four completely different ways of approaching the problem of integrating diverse media is exactly what state of the art multimedia-authoring tools offer, at least according to Dick C. A. Bulterman and Lynda Hardman, whose survey, "Multimedia Authoring Tools: State of the Art and Research Challenges," appears in the book Computer Science Today: Recent Trends and Developments (Springer-Verlag, 1995; ISBN 3-540-60105-8), other parts of which I wrote about last month.
Bulterman and Hardman see these four approaches to multimedia authoring:
Graph-based authoring, like visual or flow-chart-based programming (Sirius, Prograph), generally can be very attractive when you look at small or discrete projects, but can be problematic with large presentations containing structures that just can't be viewed at one time in one flow diagram, or when there are complex interactions among elements. For example, how do you show in a graph that you are to display the picture when the phrase "pretty picture" is spoken in the audio object?
The leading commercial multimedia-authoring tool is timeline-based: Macromedia Director. This model is probably the right one for passive multimedia; for instance, movies that can't be searched, fastforwarded, or freezeframed, if anyone is doing that sort of thing. But the timeline model has trouble defining what happens in the case of user interaction. For example, if a particular media object is activated at time T1 and runs to time T2, what is supposed to happen if the user jumps into the middle of the T1-T2 interval? (For a movie, the question is not hard, but for some kinds of media objects, it may be really messy to jump into the middle of an object's life.)
The programming model Bulterman and Hardman talk about encompasses everything from writing your own C++ library of multimedia tools to using scripting languages that emphasize rapid development above performance. They don't see this approach as very promising on its own, saying that the definition of the document can be tedious and the result may not be portable.
The structure-based approach they describe focuses on the logical structure of the presentation; you basically build an outline of this structure and defer binding its elements to actual media objects until late in the process. The authors like this structure-based approach, citing an academic system called "CMIFed" as an example, but they acknowledge that it needs to be supplemented by the other models: the timeline model in particular, with its time axis and parallel channels, seems the ideal way to describe timing relationships among media objects.
Ultimately what they opt for is a composite approach that doesn't exist yet. Maybe next generation.
The challenges facing multimedia authoring will probably do a lot to shape that next generation of tools. One challenge that the authors identify is author-once: Multimedia development is expensive, but it is more expensive than it needs to be if you have to choose a platform (Mac versus Windows versus game machine versus workstation versus smart TV versus PDA, and so on). Another challenge is adaptive media objects, objects that figure out how to display themselves on the hardware available. Yet another challenge is much-better implementation of hypertext linking for nontext objects. Because, while multimedia authoring may have concluded with burning a CD-ROM a couple of years ago, a couple of years hence it will more likely end with posting a web page.
When I write an article, I may draw on many sources, but the finished product is pretty nearly all my own creation. I may drop in a quote from Fowler or Morton or Milton, or a misquote from Raskin, but that comes under the heading of fair use (even the misquote). The same goes for the utility that you wrote from scratch the other day to solve a little problem you were having.
When you assemble a work from pieces created by others, as a movie producer or a multimedia author does, you can spend a lot of time finding those pieces and a lot more time finding out if it's okay to use them. And while it may not thrill you, it does behoove you to know a little law. Two books that recently came over the transom here at Stately Swaine Manor can be helpful with those two problems: finding the stuff and then finding out if you can use the stuff you found. I thought I'd also mention a few other related books that you might want to know about.
Multimedia Law and Business Handbook, by J. Dianne Brinson and Mark F. Radcliffe (Ladera Press, 1996; ISBN0-9639173-2-3), is nicely organized and readable, and seems to cover the ground. The book is a revision and expansion of their 1994 Ladera Press book Multimedia Law Handbook, and it's a big improvement. The new book begins with a description of the U.S. legal system that puts the rest of the book in perspective and also lets you know, for example, where you would go to seek arbitration of a dispute. It zips through copyright, patent, trademark, and trade secret law, and then gets detailed regarding contracts, development agreements, work for hire, consultants, and contractors. It talks about licensing content on an industry-by-industry basis, and touches on privacy and libel and post-production legal concerns. And it has two chapters on online and educational issues. If you are doing multimedia development and can only buy (or stand to read) one book on the law, this is it.
Web Developer's Guide to Sound and Music, by Anthony Helmstetter and Ron Simpson (Coriolis Group, 1996; ISBN 1-883577-95-0), is primarily about the technology of sound, not the law of sound, but it does have some good advice on where to find (or how to create) music and sounds that you can use in your multimedia web creations, with sections on licensing content, contracting talent, running a recording session, and finding the right recording studio.
There are probably some legal issues that come up more often in multimedia development than in movie making (patents? legal liability?). If so, a reference book or two on software law would be handy to have on your multimedia law bookshelf. The Software Developer's and Marketer's Legal Companion, by Gene K. Landy (Addison-Wesley, 1993; ISBN 0-201-62276-9), is a nice fat book that discusses international issues and distribution agreements along with all the issues covered in other books, such as Nolo Press's good offerings: How to Copyright Software, by M. J. Salone (first edition 1984; ISBN 0-917316-79-7, with many subsequent editions); or Legal Care for Your Software, by Daniel Remer and Stephen Elias (first edition 1982, third edition 1987; ISBN 87337-037-6]; Patent It Yourself, by David Pressman (first edition 1985; ISBN 0-87337-075-9]); and Nolo's Patent, Copyright & Trademark Intellectual Property Law Dictionary (first edition 1985; ISBN 0-917316-97-5). Some legal iissues, though, are probably best understood from the viewpoint of a producer. The Complete Film Production Handbook, by Eve Light Honthaner (Lone Eagle Publishing, 1993; ISBN 0-943728-41-X), is good for legal issues relating to actors, as well as for general production advice.
Finally, if you're going to put it online, there's Online Law: The SPA's Legal Guide to Doing Business on the Internet, Thomas J. Smedinghoff, editor (Addison-Wesley, 1996; ISBN 0-201-48980-5). Issues dealt with that aren't in the other books (I think) include the legalities of obscenity and pornography, digital signatures, and buying and selling online.
This summer the Computer Professionals for Social Responsibility (CPSR) launched a web site (http://www.reach .com/matrix/community-memory.html) and discussion list for people interested in the history of computing. The list, called "Community Memory," is moderated by David S. Bennahum. Its mission is "to explore the origins, history, and development of computer networks, computer hardware, software, and computer science, and the environment collectively known as 'cyberspace.'" You can subscribe by sending a message to listserv@cpsr.org with "subscribe cpsr-history <your first name <your last name" in the body of the message.
CPSR is trying to get anyone with an interest in computer history to join the list, but it's particularly interested in getting people who can provide first-hand accounts of their involvement in the creation of important technologies and organizations, from the 1940s through today. There's a certain amount of that sort of primary-source record-keeping happening on the Net already, but it's all pretty haphazard. It would be a good thing if the CPSR site or some such site became a magnet for people who have real stories to tell about the history of computing. If you have such stories, I urge you to offer them to David.
The name "Community Memory" honors the Community Memory project that some of you may remember. That Community Memory was the world's first public-access computerized bulletin board system. Starting with an ASR-33 terminal outside Leopold's Records in Berkeley, California, a time-shared XDS-940 mainframe in a San Francisco warehouse basement, and a 110-baud link, the original Community Memory project set out to bring people together in an uncensored, decentralized, non-bureaucratic electronic network where connections were made on the basis of shared interests. Sound like anything you know? Yes, but this was in 1972, seven years before two graduate students at Duke University strung some wire between a few tin cans running UNIX and invented Usenet.
I hope that one of the historical threads followed on the Community Memory list will be the history of the original Community Memory project. I've seen accounts that describe it as quite short-lived, running from 1972-1974, but my research indicates that Lee Felsenstein (the designer of the Processor Technology Sol and Osborne One computers and one of the founders of the Community Memory project) was funneling his earnings from Processor Tech into Community Memory in 1977, and I remember it being active well into the 1980s. For all I know, it's still alive. I guess I could ask Lee. But if Lee joins the list, I could ask him publicly there, and then a lot of people would have the answer.
The original Community Memory had some of its meager bandwidth given over to less than serious messages, like:
U.S. GET OUT OF WASHINGTON
FREE THE INDIANAPOLIS 500
...or maybe those were the serious messages. Here's an arguably less than serious example that gives the flavor of the new Community Memory list, while understating the seriousness of most of the discussion:
One contributor wants to know:
>Where did the emoticon originate?
A prompt and plausible answer comes back:
>One source...attributes the smileys to Scott Fahlman of Carnegie Melon U
>about 14 years ago.
Then several more messages are posted, reiterating this story, adding a reference to the unimpeachable source on all such matters, the Jargon File at http://www .eps.mcgill.ca/jargon/jargon.html, and setting the date as 1980. These are followed by the first alternate theory:
>In his column in the June 96 issue of "Fantasy & Science
Fiction," Gregory
>Benford writes: Most of the Net's 'emoticons'...appeared in fanzines by
>the 1940s."
...which is quickly challenged:
>It wouldn't be the first time Greg stretched the truth to make a point.
At this point a new strain of data arrives, casting doubt on the original theory:
>...first seen on ASR33 teletype circa 1969-70, and Burroughs Series E
>generated invoices...(1972)
Although, how many Burroughs Series E generated invoices are still around? Finally, or at least at the point where I became discouraged, a historian suggests that the true answer may be buried in a place where she did not have the courage to search:
>When researching a book on the history of the Net...my co-author and I
>did an archeological dig through thousands of messages on one of the
>earliest mailing lists...and we were intrigued to see a posting from
>someone in 1979 suggesting the use of punctuation marks in e-mail to
>express nuances/emotions etc. He had gotten the idea from a Reader's
>Digest article, but we would have had to search through hundreds of old
>Reader's Digests to find what he was referring to, exactly. His
>suggestion, btw, was pretty summarily shot down.
BTW, since I didn't want to deal with a lot of alternative theories, I based that story largely on my own research. I was happy to see that I agreed with me 100 percent. That research first saw the light of day in my book, Fire in the Valley, a history of the making of the personal computer, which, I'm sorry to say, is out of print and unavailable. It may become available again in another form, though: It's the book that movie producer was asking about. Anyone interested can follow developments at http://www.cruzio.com/~mswaine.