According to tiny anthropomorphic hamsters huddled in a corner at Bloomingdale's pre-opening gala, Be, Inc. will be releasing its software MIDI synthesizer later this month. This will allow MIDIphiles to play MIDI files using the audio output of the BeBox without having to connect to an external MIDI player. It also provides an easy way for application developers to add a soundtrack and sound effects to their applications.

The software synthesizer is based on the wavetable synthesis engine SoundMusicSys, licensed from Headspace, Inc. SoundMusicSys was created by Steve Hales and Jim Nitchals and has achieved considerable popularity among game developers. The SoundMusicSys engine supports Headspace's RMF (Rich Music Format), a cross-platform open standard for musical expression (see www.headspace.com for more about RMF).

The software synthesizer also supports the General MIDI Specification, which is a mapping from MIDI program change numbers to instruments. An application can play ocarina sounds, for example, by sending a program change number 79 (ocarina) to the synthesizer on one of the sixteen MIDI channels. The synthesizer will then respond to a note-on message on that channel by mixing an appropriately pitch- shifted ocarina sound into an audio stream (usually the DAC stream).

A high-quality General MIDI instrument sample library was developed specifically for the BeOS by Peter Drescher of Twittering Machine Productions. The library includes a complete set of 127 instruments, plus a percussion bank, and contains about 5 MB of samples. The instruments are sampled at 22 KHz, 16-bit resolution. While they're designed to be able to play a wide range of General MIDI files in a variety of musical styles, special attention was paid to creating a lifelike effect from the acoustic instruments.

The SoundMusicSys engine can play user supplied samples as well as sounds from the sample library; and a selection of built-in reverb effects can be applied to the samples.

Interested developers should pay close attention to the Be web site, where a sample application capable of rendering MIDI files to audio will be appearing, followed shortly by an API to the synthesizer along with source code to the sample application.

The next major release of the BeOS, Developer Release 9 (DR9), will include a significant overhaul of our mainline C++ libraries. Many of these changes should make development on the BeOS much more flexible. The major new features planned for inclusion are C++ I/O streams, support for exceptions, and an implementation of the C++ Standard Template Library (STL).

Most programmers should be familiar with the first two features. I/O streams provide an easy way to abstract file I/O. C++ exceptions provide a mechanism by which the programmer can handle unexpected or error conditions and relay them to other parts of the program. Both of these are described in detail in any good C++ book.

The third new feature, STL, has been a part of the ANSI C++ standard since 1994. STL is a powerful and efficient library that aggressively uses templates to provide a set of useful C++ container classes and generic algorithms. These classes and algorithms provide an easy way to construct and operate on new and complex data structures.

The details of STL can get rather hairy and may take some time to understand properly. This article provides a very brief description of the elements of STL and a few examples of their use.

STL consists of five elements:

• "Algorithms" are template functions that perform operations on containers.

• "Containers" are objects that contain other objects and perform memory operations on them.

• "Iterators" are methods that specify the location of a container or stream, for use by an algorithm.

• "Function objects" encapsulate functions in an object for use by other components.

• "Adaptors" adapt components to provide different interfaces; they translate between classes.

STL extends basic C and C++ programming paradigms, making it easy to start using the library. For example, STL provides a generic sorting algorithm, appropriately named sort().

The following code fragment demonstrates how sort() can be used to sort the elements in a "normal" array, as well as on the STL "vector" container:

double a[1000];
vector<double> b;
...

// sort all the items in the array
sort(a, a + 1000);

//sort all the items in the vector
sort(b.begin(), b.end());

As with all STL algorithms, the sort() algorithm is generic: It accepts regular pointers as its arguments, as well as the STL-defined "iterators" (location specifiers) that are returned by the begin() and end() calls.

Note that there are various kinds of iterators. The type of the iterator defines its use. For example, input iterators provide access to data sources. Output iterators provide access to data sinks. These can be explored further as the programmer delves into STL.

The library provides a number of container types. In addition to arrays ("built-in" containers) and the vector type demonstrated above, STL provides lists, queues, sets, and stacks, to name a few. These are all templates, so you can have a list of ints, set of Employees, and so on, without doing much work at all.

Here's a simple example taken from the web that once again uses the vector container type (see http://www.cs.brown.edu/people/jak/programming/stl-tutorial/tutorial.html for more examples):

#include <iostream.h>
#include <algobase.h>
#include <vector.h>

main (int argc, char *argv[])
{
  int n = atoi (argv[1]); // argument checking removed for clarity

  vector<int> v;
  for (int i = 0; i < n; i++) // append integers [0, n-1] to v
    v.push_back (i);

  // shuffle
  random_shuffle (v.begin(), v.end());

  // print to stdio
  copy (v.begin(), v.end(), ostream_iterator<int> (cout, "\n"));
}

This program generates a random permutation of the first 'n' integers, where 'n' is specified on the command line. Believe it or not, the algorithm random_shuffle() is defined in STL.

The last line of this program may be a bit confusing. The STL copy() algorithm takes three iterators. The first two specify the source range and the third is the destination. Here, the third argument, ostream_iterator<int>(), is an "adaptor." The adaptor converts the integer vector into an output stream. Assigning to ostream_iterator<int> writes data out. The two arguments to the ostream_iterator<int> constructor are the output stream and the element separator.

In summary, STL provides a concise and efficient way of constructing and operating on a variety of data structures. What I've presented above are the bare essentials; there are many other ways these template classes can be used. Look forward to using them in DR9!

Before I was married, I used to work all the time. Lucky for me, my future wife worked with me. That's 24-hour-a-day exposure to my spouse to be!

When we were married, we vowed, among other thing, to not work on weekends, and not only that, but we didn't keep a machine at home either. What a time squeeze. At the time we were doing a lot of NeXT development and were pretty proficient at it, so things were OK.

Before my daughter was born, I got in the habit of exercising to think quickly. I figured there wouldn't be much time to write buggy code accompanied by long hours of debugging. So, what to do? I know, use frameworks and plug- ins extensively. Object-oriented programming has been given a bad wrap. Encapsulation at least is a key development methodology, which works very well in many situations, and add-ons implement encapsulation beautifully.

One advantage that the BeOS has as a new operating system, starting relatively from scratch, is that we have a lot of good and bad examples to look at. This is true for both the OS code itself and the applications that we encourage developers to write. An application like, oh, I don't know... Lumena, was pretty good, took a long time to develop, and couldn't keep up with the times.

We can learn from this. We can emulate functions and features, and best of all, we know what the architecture of the application should be. I would argue that the architecture, or framework, upon which the application is built is one of the most important factors that will influence how gracefully it ages over time. A framework that supports add-ons will at least be more easily updated and possibly more extensible than its traditional monolithic counterpart. And even at that, we've learned a lot about how to make add-ons work most efficiently. So like today's OS that learns from the pros and cons of the past, applications do the same thing.

As an example, last week I released the first version of Rraster! This is a simple example of how to support add-ons using the BeOS. The application is simple, it's meant to be an add-ons aware image viewer. I would put it in the category of esoteric software, because although this particular category has launched such products as Photoshop and DeBabelizer, this really is a mundane feature that no OS should be without.

My nanny was deathly ill last week, so I spent at lot more time with my daughter. When you're with an 18-month old you don't have a lot of time to think, let alone code. But I had to stay productive, so what to do? Write more Rraster add- ons. So this week I've updated Rraster. I managed to add support for the following file formats:

GIF, PCX, PBM, TIFF, TGA, PNG, JFIF, XBM, and BMP

I didn't quite have enough time for PICT or other Mac formats, but what can you expect for coding that has to occur between diaper changes. Then I was about to take a whack at filter plug-ins and the weekend parties and visiting started.

You can get the latest at:

ftp://ftp.be.com/pub/Samples/Rraster.tgz

Of course all this source is for you to be able to write your own favorite image plug-in and to see how add-ons can be supported in general.

In 1987, most pundits started predicting that multimedia was poised to become the next revolution in computing. I believe this was the time when the P word, paradigm, as in "paradigm shift," started to creep into execuspeak. Others felt multimedia was the simple but important continuation of an old trend: With great regularity, more of (almost) everything was offered to hardware and software engineers. As a result, the computer increased its range of media and, to a large extent, it handled it more gracefully with the passage of time.

There was a time when multimedia meant multiple slide projectors and a tape player; when the multimedia dust settled for a brief moment before the rise of the web, multimedia had come to mean a CD-ROM, loudspeakers, color, music, and animated graphics. At Apple, in the early days of the new era, we were both clueless and bombarded—from outside and, as a result, from the executive suite. We were clueless because, while we liked more interesting, livelier computers, at that time we had no idea what the next multimedia "killer app" would turn out to be. We were bombarded with suggestions and demands from the outside world. (This is a long-standing tradition for Apple, one that seems to perpetuate itself today with suggestions to adopt a certain operating system.)

For instance, in those days technological haruspices were clamoring for the adoption of DVI, an Intel-sponsored asymmetric video compression technology, and there were big debates about CD-I, the "I" standing for interactive. Japanese companies were trying to enter the market with a new kind of multimedia personal computer, the CD-I PC. There was panic, we must have a statement of strategic direction, and collateral damage, the overproduction of overhead transparencies. The search for the multimedia Holy VisiCalc wasn't going well. Video looked attractive, "compelling" was the buzzword. Other had their doubts, based on a combinations of psychological and business arguments. They saw the classical productivity applications as tools, used repeatedly and valued accordingly. Video was perceived as more ephemeral. Captivating, entertaining, but few customers, if any, would use the same video over and over again. And for entertainment, why bring TV to the computer screen?

Sensing the potential, but unable to divine the killer app, I made a bold move: I hired a childhood friend of Larry Tesler, Marc Porat, with the mission to scour Apple's technology portfolio and build a multimedia strategy. He came up with General Magic instead. But there was hope. One researcher in Apple's Advanced Technology Group wrote a short paper summarizing the notion of "genre." The genre expresses a convention, an agreement combining the expressive ways of authors and the expectations, the habits of an audience. The same physical medium can harbor many genres: Newspaper, book, newsletter, encyclopedia on paper, or comedy, tragedy, musical comedy on stage. That paper transmuted the Holy PageMaker question into one of new, emerging genres. We now know a little more. In many ways, the CD-ROM has become synecdoche for multimedia, and a few distinct genres have emerged for the new medium: Games, reference, software distribution, the questionable edutainment, and lately, back-up, admittedly not very multimedia nor totally ROM. All self-respecting PCs now have a CD-ROM drive, speakers, and reasonable audio and video capabilities.

The Internet poses even more interesting genre questions. We have e-mail, news, web pages... E-mail meets the definition of genre very well: Expectations, audience, expression, the ingredients are there. The same is true for news. Things get more confusing for web pages. One can argue company and personal pages are gaining the stable conventions required to qualify. But the proliferation of information has created an opportunity for new genres: Search and delivery.

In a way, General Magic was onto something and investors were lured by the promise of intelligent agents. Newspapers use intelligent humans to sort and present information to us. Humans and computers in concert are likely to create one or two stable genres mining the web for us and providing us the combination of the expected and the pleasantly unexpected, for which we'll be willing to part with some of our money. Which is another genre criterion.

BeDevTalk is an unmonitored discussion group in which technical information is shared by Be developers and interested parties. In this column, we summarize some of the active threads, listed by their subject lines as they appear, verbatim, in the mail.

To subscribe to BeDevTalk, visit the mailing list page on our web site: http://www.be.com/aboutbe/mailinglists.html.