Jesse "The Body" Ventura is now the governor of Minnesota. He has, so far, upped his mark on history from being the only gubernatorial candidate to use the theme from "Shaft" in his campaign ads to also being the only former pro wrestler to be elected governor. To all of us here at Be, Jesse "The Body" is a shining example of a third-party candidate who can beat the odds to win out over the incumbent and deliver what his constituents really want. All it takes is some gumption, a great product, and a fab set of pects. Between JLG and the rest of us here at Be, I think we've got what it takes. Jesse, we salute you!

The app server has been vastly restructured in BeOS Release 4. Or, to put it another way, the restructuring that I began in Release 3 has been largely completed in R4. The app server is about 25,000 lines of code slimmer. Of the remaining code, probably less than 40% of it has not either been modified significantly or replaced with new code. For the graphics team, R4 is certainly the most significant release we've been involved in.

Much as I would love to brag about all the great stuff that's changed internally for the better, I'll restrain myself. Suffice it to say that the R4 app server is fundamentally much more robust, scalable, and sexy. It's also faster—in some extreme cases, several orders of magnitude faster.

That said, the features that we've introduced in R4 are not really so innovative per se. For the most part they're features that other operating systems already have, in one form or another. In this way, R4 has been sort of a "catch-up" release for the app server team, expanding our feature set to better support applications that are coming online to access the performance BeOS gives them.

"Yeah, blah, blah, blah. How about a feature list, dude?" OK. Those of you with copies of the beta, follow along at home! For the rest of you, don't worry, you'll see it soon enough.

void ClipToPicture(BPicture *picture,
                   BPoint where = B_ORIGIN,
                   bool sync = true);

void ClipToInversePicture(BPicture *picture,
                          BPoint where = B_ORIGIN,
                          bool sync = true);

void SetBlendingMode(source_alpha srcAlpha, alpha_function alphaFunc);

status_t SetEventMask(uint32 mask, uint32 options=0);
status_t SetMouseEventMask(uint32 mask, uint32 options=0);

void SetViewBitmap(constBBitmap *bitmap,
                   BRect srcRect,
                   BRect dstRect,
                   uint32 followFlags = B_FOLLOW_TOP|B_FOLLOW_LEFT,
                   uint32 options = B_TILE_BITMAP);

void SetViewBitmap(constBBitmap *bitmap,
                   uint32 followFlags = B_FOLLOW_TOP|B_FOLLOW_LEFT,
                   uint32 options = B_TILE_BITMAP);

void ClearViewBitmap();

void StrokeShape(BShape *shape,
                 pattern p = B_SOLID_HIGH);

void FillShape(BShape *shape,
               pattern p = B_SOLID_HIGH);

void GetGlyphShapes(const char charArray[],
                    int32 numChars,
                    BShape *glyphShapeArray[]) const;

As the fog rolls over the mountains and threatens to envelop the Stanford Dish in a thick, cottony blanket, the setting sun breaks through for the first time on this brisk November day in Menlo Park, casting lukewarm light across the tree tops, and painting sharply contrasting shadows against the ubiquitous office-beige walls of my repo-depot erector set of a cube. I am a Be engineer.

So my day continues into the night in the countdown to Release 4. After spending my summers here as an intern, I've recently joined the Be team full time, with a mission to maintain what is known as "the Installation Experience." Welcome to the BeOS, may I take your order?

They (in the proverbial sense) say that one never gets a second chance to make a first impression. Just as your first handshake can tell the father of the girl you're dating that you're not a complete moron and are worthy of spending time in a well-lit, crowded place with his little princess, the installation process is frequently the first real exposure new users have to our product. That's why we'd like to make it as smooth and pleasurable as possible. This is what now rests on my shoulders.

There are two essential goals in writing almost any piece of software: simplicity and utility. In many cases "simple" is synonymous with "intuitive." I like to use a completely unscientific metric for quantifying simplicity in terms of the number of instructions read and number of mistakes made before one has a comfortable basic working knowledge of a given tool.

User manuals are rarely read. Therefore, it's important that a tool (however well-documented) have a base functionality and interface that allows users to "jump right in" and start being productive with a minimal amount of knowledge. This is easy if a program doesn't do much, but it becomes more difficult with a feature-rich everything-but- the-virtual-sink utility.

The trick is to present a tool's features in a logical, intuitive way. If a word processor requires users to learn a new scripting language -- documented only on an obscure overseas BBS whose number is listed on the CD-ROM on which the program is distributed—in order to change a font size, chances are that the interface could use some rethinking. The tool may be useful—it may let you capitalize every other letter of every third word in paragraphs beginning with the phrase, "It was the best of..."—but that functionality (however useful) will be hidden from most users if the interface is cryptic. Even expert users will be reluctant to use your features if they are inaccessible; intuitive interfaces are not just for neophytes.

In the case of the BeOS installer, these goals are two-fold. We'd not only like the BeOS to be easy to acquire, configure, and run, but we also want our developers to make a similar first impression. This is why I've undertaken the task of giving our installation utilities a major overhaul. My goal is to provide a more feature-rich set of tools that are easy to use for both developers and end users.

We've got the simplicity, now it's time to add some features. The current BeOS Installer is the result of efforts to maintain the ease of installing the OS. The notion of the "one button install" is a powerful one, and I believe it should be maintained. One badly needed feature that seems to be missing from the vocabulary of BeOS installers, however, is an "uninstall." Another welcome feature would be the ability to back out in the middle of an installation without affecting the volume onto which the package is being installed. From a developer's standpoint, I'd like to see more flexibility than just a "standard" install and an "optional" install. These are a few of many improvements that could be made.

I've just recently joined the team, so watch for an installation overhaul in Release 5. This gives you plenty of time to send in your feature requests (what do you want to install today?). Let me know if there's anything you can't live without or would find useful in a package creation or installation utility, and I'll worry about making it fun and accessible. You can e-mail your suggestions/comments/requests to <mattb@be.com>. As my Desktop background continually reminds me, I only have two more releases to buy one of these:

http://www.yamaha-motor.com/sport/products/modelimage/8/1/0/image.aspx
[Editors' note: Hopefully this is the correct URL as the page has moved between 1998 and 2006]

So I guess I'd better get back to work.

It was one year ago this week that I wrote my first Be Newsletter article, called "Sounds That Go Bump in the Night." In it, I explained how to play sound under the Preview Release 2 and Release 3 Media Kit. That was by subscribing to the audio stream, then filling buffers with 16-bit stereo audio data as it passes through your stream hook function.

Now we're on the brink of unleashing the new and improved BeOS Release 4 Media Kit, and it's a whole new ballgame. This article covers the new Media Kit's audio capabilities, with a special focus on updating existing applications to use the new API.

If you're not familiar with the Release 3 Media Kit, you don't really need to know how to update your applications, but if you're curious, you can read my two articles on sound playback in Release 3:

Developers' Workshop: Sounds That Go Bump In the Night

Developers' Workshop: Daddy, Where Does Sound Come From?

Sound playback in the Release 4 Media Kit is done with the BSound and BSoundPlayer classes. BSound represents a sound (either on disk or in memory), and BSoundPlayer provides functions for playing sound, either by playing a BSound, or by receiving buffers that you can fill in with audio data and pass along.

The former method is the easiest to use for new applications. Depending on the needs of your Release 3 Media Kit application, it may be easier to use BSound and BSoundPlayer together than the second method, which in many ways is similar to the previous Media Kit's stream hook function method for playing sounds.

Under Release 3, your sound playing code always involves a hook function that receives buffers from the Audio Server, fills them with data, and passes them along down the audio stream. This is usually overkill, especially if all you're doing is playing a sound from disk (see Developers' Workshop: Daddy, Where Does Sound Come From? for sample code on how this was done in Release 3).

Here's code that plays a sound from disk using the Release 4 Media Kit:

#include <MediaDefs.h>
#include <Sound.h>
#include <SoundPlayer.h>
#include <Entry.h>
#include <Path.h>

void playsound(char *path) {
  BSound *sound;
  BSoundPlayer player;
  entry_ref ref;
  BEntry entry(path, true);
  BSoundPlayer::play_id id;


  if (entry.InitCheck() == B_OK) {
    if (entry.GetRef(&ref) == B_OK) {
      sound = new BSound(&ref);
      if (sound->InitCheck() == B_OK) {
        player.Start();
        player.SetVolume(1.0);
        id = player.StartPlaying(sound);
        sound->ReleaseRef();
        player.WaitForSound(id);
      }
    }
  }
}

This function accepts a pathname as input, and plays the sound in the specified file. It doesn't return until playback is complete. Let's see how it works.

The most interesting local variables here are the BSound* and the id variable. BSound* is a pointer to the BSound object that represents the sound on disk, BSoundPlayer, which is the object that handles playing the sound. The id variable, of type BSoundPlayer::play_id, contains the ID number assigned to the sound by the BSoundPlayer when we start playing it.

The first thing it does is obtain an entry_ref for the path (using BEntry::GetRef()). Then a BSound object is instantiated, using that entry_ref. This sets up the BSound object to reference that file. There's also a form of the BSound constructor for creating sounds that are kept in memory.

Once the sound is instantiated, and we've checked to be sure it was done successfully, we start up the BSoundPlayer by calling Start(), set the volume to maximum by calling SetVolume(), and then start playing the sound using the StartPlaying() function.

The BSoundPlayer class can play as many sounds as you want (as long as every sound you play through a given BSoundPlayer is at the same sampling rate). That's why StartPlaying() returns an ID number. If you want to check the status of a sound, or stop it, you use that ID number to specify which sound you're interested in. For instance, you might want to call IsPlaying() to determine if the sound is still playing.

Once the sound has been started, we call BSound::ReleaseRef() on the sound to mark the sound to be deleted once playback is finished. That means that as soon as the BSoundPlayer is done with the sound, the BSound object is automatically deleted. Then we call BSoundPlayer::WaitForSound() to wait until the sound has finished playing.

If we wanted the playsound() function to be asynchronous, we would just remove the call to WaitForSound(), since we've arranged for BSounds to be deleted automatically when they're done playing.

That's the easy way to play sound in the R4 Media Kit. But what if your playback needs are more involved? Maybe your code needs to adjust the sound during playback, or your sounds are generated on the fly. The BSoundPlayer class can help you there, too.

BSoundPlayer supports the ability to specify a play buffer function that is called for every buffer that passes through the sound player's node. This lets you fill these buffers with whatever sound data you want. You create a BSoundPlayer for this purpose by either specifying the play buffer function when you instantiate the BSoundPlayer, or by calling BSoundPlayer::SetBufferPlayer() or BSoundPlayer::SetCallbacks(). You can also specify a cookie (application-specific data) that is passed to the play buffer function each time it's called.

In this example, we'll use stereo floating-point audio at 44.1kHz (this is the preferred format in the R4 Media Kit; floating-point audio is used internally, so by using it in your applications you can reduce overhead by preventing unnecessary format conversions). We'll create a play buffer function that plays a continuous triangle wave. The cookie tracks where we are in the wave across calls to the play buffer function. Here's the structure for the cookie:

typedef struct cookie_record {
  float value;
  float direction;
} cookie_record;

The main program instantiates the BSoundPlayer and handles running the sound. Since we're using the Media Kit's native sound format, we don't have to specify a media raw audio format structure to tell it what format to use. If we wanted to use, say, 16-bit stereo, we'd have to provide a media raw audio format structure to the BSoundPlayer constructor.

Keep in mind that Be reserves the right to change the default format. In fact, it's almost guaranteed to change over time as the Media Kit evolves, so you shouldn't assume that floating- point 44.1kHz stereo is the default. If you care, you should set it explicitly.

cookie_record cookie;
cookie.value = 0.0;
cookie.direction = 1.0;
BSoundPlayer player("wave player", BufferProc, NULL,
  &cookie);

We now have a BSoundPlayer that's tied to a play buffer function called BufferProc(). It receives a pointer to our cookie each time it's called.

Here's some simple code that starts and stops the tone:

player.Start();
player.SetHasData(true);
getchar();      /* wait until return is hit */
player.Stop();

The BBufferPlayer::Start() and BBufferPlayer::Stop() functions start and stop the playback, as in the previous example. The SetHasData() function is new: it tells the BSoundPlayer that our play buffer function is in fact ready to generate audio data. Your play buffer function won't be called until this has been done. When you don't have sound to play, you should call SetHasData(false) so the Media Kit doesn't keep calling your play buffer function when there's no sound to play; this improves performance.

Now let's have a look at the BufferProc():

void BufferProc(void *theCookie, void *buffer, size_t size,
       constmedia_raw_audio_format &format) {
  size_t i, j;
  float *buf = (float *) buffer;
  size_t float_size = size/4;
  uint32 channel_count = format.channel_count;
  cookie_record *cookie = (cookie_record *) theCookie;


  if (format.format !=
        media_raw_audio_format::B_AUDIO_FLOAT) {
    return;
  }


  for (i=0; i<float_size; i+=channel_count) {
    for (j=0; j<channel_count; j++) {
      buf[i+j] = cookie->value;
    }
    if ((cookie->direction == 1.0) &&
        (cookie->value >= 1.0)) {
      cookie->direction = -1.0;
    }
    else if ((cookie->direction == -1.0) &&
             (cookie->value <= -1.0)) {
      cookie->direction = 1.0;
    }
    cookie->value += cookie->direction*(1.0/64.0);
  }
}

This function (if you're familiar with the Release 3 Media Kit) is the R4 equivalent of the enter stream hook function used when you subscribe to a BDACStream to pump audio buffers into the stream. The key difference is that in this case, the buffers are yours and yours alone; you should replace their contents with your own data. In Release 3, you received buffers containing data provided by other applications that were playing sounds.

The code begins by setting up some local variables. A local pointer to the audio buffer is created, of type float*, since that's the format of the data we'll store in the buffer. We compute float size, the number of floats in the buffer, and we fetch the channel count out of the media raw audio format structure we receive that describes the audio format. We also set up a pointer to the cookie of the correct type.

Then we check to be sure that the buffer's audio format is in fact floating-point by comparing its format to the value media_raw_audio_format::B_AUDIO_FORMAT. If it doesn't match, we return without doing anything.

Then we enter a loop that fills out the buffer with data. How this works isn't really important. You can replace this code with whatever you want in order to provide the sound you require. The only interesting thing to note is that parameters for building the audio are pulled from the cookie, and updated values are stored back into its fields before the BufferProc() returns.

If your Release 3 Media Kit application simply plays sound, you should be able to use one of these two methods to update your R4 Media Kit application easily. If your code is straightforward, and plays sounds unaltered, you may find it easier to use the BSound and BSoundPlayer combination to perform the audio. If your enter stream hook function is more complex, performing audio generation on the fly, the play buffer mechanism should let you update your application without much effort.

About the only applications that can't readily be updated to the R4 Media Kit by using these two classes are those that filter the audio output by other applications, or applications that record audio. For these, you'll have to look deeper into the Media Kit.

As I write this, we're in a conference room in Hitachi's Personal Computer Division headquarters, near Shin Ochanomizu in Tokyo, just steps away from the geek Mecca of Akihabara. We're working on the last details of presentations to introduce three Hitachi Flora Prius systems bundled with Gobe Productive and Adamation Personal Studio applications for the BeOS, in a partition next to the standard Windows 98 binaries.

This event is a little more complicated than usual, but it's a happy one nonetheless. Some time ago, we made a commitment to the Japanese market, based on reasons and emotions I've discussed in prior columns. Japan is, after all, the birthplace of much digital media technology. It is a market of technophiles and, in contradiction to the conservative stereotype affixed to its culture, fairly comfortable with unproven ideas.

It also didn't hurt that a number of us at Be are unabashed Japanophiles. Singling out anyone's contribution in integrated work such as ours could be unfair to the rest of the team, but today's occasion reminds me that we wouldn't be here without one of our engineers, Hiroshi Lockheimer, who made sure we have a truly Japanese version of the BeOS.

From where I sit, I can see Bob Hearn, Gobe's CTO, entering Japanese text in a Productive document for his demo. One of the complications mentioned earlier involved flying Bob out of Hawaii, hours after his sister-in-law's wedding. Stephan Adams also made the trip to introduce Personal Studio. All of us, including Jim Cook, Michael McBride, and myself, along with spare equipment and software in a broken case, a translator and a number of our Hitachi hosts, are now rehearsing a four company presentation in two languages (and more accents). Our audience is dailies in the morning and magazines in the afternoon.

The good news is that Hitachi PR people are running around looking for a bigger room—it looks like we'll have more media people than originally planned. Or else our Hitachi friends know the rule regarding the number of seats in the room before a presentation: stack half the chairs in a corner and make a spectacle of putting them back when the available ones are filled. That way the presentation starts with an audience that thinks it's larger than planned. Or, if only half the people you expected show up, you don't start with a group of people wondering why the other half haven't bothered to attend.

The preparation is meticulous and high tech. Hitachi requests a change in my presentation, I scribble it on a piece of paper; Morita-san, the translator, edits a slide on his PowerBook, and e-mails the changes. The new color-printed hand-outs are produced somewhere else in Tokyo. I notice he's using a tiny Kenwood wireless phone—at ISDN speed, I'm told—from the inside of a reinforced concrete building. Unlike a dedicated modem such as the Ricochet, this uses a standard digital phone. It appears faster, more reliable, and more common than what we enjoy today in the US or in Europe.

Hitachi and our Japanese distributor, Plat'Home, have supported the BeOS from the beginning of its market life. Month after month, Plat'Home has generated a disproportionately high percentage of our sales volume. They also introduced us to Hitachi, leading to the present joint effort. Interestingly, after taking a long look at the BeOS and at the marketplace, Hitachi came to its own conclusions—remarkably similar to ours—regarding what they call "media creation and browsing," the respective capabilities of Windows 98 and of the BeOS, and their coexistence.

During Hitachi's pre-introduction briefings to selected media, one question was asked repeatedly: Why does Hitachi, a very conservative company, make such an unconventional move? This is more the style of Sony.

Somehow, this seemed to make Hitachi executives happy.