The new Midi Kit in the upcoming Maui release of BeOS provides more flexible interconnection of Midi objects, while remaining backward compatible with the old Midi Kit. We chose not to integrate the Midi Kit into the Media Kit as another media type, mainly because MIDI doesn't require any of the format negotiation that other media types need. We did put a familiar face on the new Midi Kit, though. There's a MidiRoster for finding or registering BMidiConsumers and BMidiProducers, but without multiple virtual inheritance this time. That means you can't create an object that's both a BMidiConsumer and a BMidiProducer. Also, rather than use token structs like media node to make connections via the MediaRoster, the new kit makes the connections directly via the BMidiProducer object. And timing in the new kit is in microseconds instead of milliseconds.

My favorite application of MIDI is real-time control. I've written a class that does all the dirty work of sending the right messages to a cool new controller, as an example of how you can use the new MIDI Kit. You'll find the code here soon:

<ftp://ftp.be.com/pub/samples/midi kit/motormix.zip>

The Motor Mix is a MIDI controller from CM Automation <http://www.cmautomation.com/> that has channel strips with motorized 100mm faders, 5 buttons with LEDs, and a continuous pot controller. It also has a two-character-high LCD for a "scribble strip" and for indicating the positions of the pots and a few dozen other function keys. It was designed to be integrated into audio applications as a more natural control surface for audio mixing applications. The Motor Mix uses MIDI as its communication method, sending and receiving continuous controller messages for each slider and switch that is manipulated. If you're developing an audio application and would like the Motor Mix to be fully integrated into it, please contact Pete Montessi at CM Automation for more information.

The sample code includes an object that represents a Motor Mix controller that you can use in your apps. The class contains both BMidiConsumer and BMidiProducer objects that it uses to send and receive MIDI data to the controller. It also manages the connection with the consumer and producer that represent the Midi device. The app needs to supply the appropriate Midi device to connect to. The MotorMix class has functions to move the faders, set the state of the LEDs in the switches, and set the characters in the display. To receive messages from the Motor Mix, you have two options. You can subclass the MotorMix object and override the hook functions for each message, or you can call SetMessenger with a BMessenger pointed at the handler that you want to receive the messages. As an example, I've created a window with controls laid out just like a motor mix that mimic the current state of the controller.

In an effort to make your debugging life easier, I thought I'd write an article documenting the BeOS memory map. Knowing where things get loaded can be pretty helpful when reading stack crawls, using the leak checker, and printf()'ing pointers.

As you've probably heard, BeOS uses protected memory. What that means is every app has its own 32-bit virtual address space (about 4 billion bytes), and cannot directly view memory from the system or other apps. For example, a given location in my app (let's say 0x80002000) does not contain the same data as the same address in another app's address space. This is why you can't pass meaningful pointers between applications, and why one badly behaved program can't trash the memory of others.

BeOS R4.5 places data in memory as follows. I want to emphasize that this is how the current release behaves, and while we don't have short term plans to change it, these locations are not written in stone:

0x00000000 - kernel
0x80000000 - application code
heap follows code
0xea000000 - addons
0xec000000 - libraries
0xfc000000 - stack

In addition, you might have:

0xd0000000 - app server shared data
0xa0000000 - net server shared data

Let's go through these in turn.

Memory between 0 and 8 bazillions, as they are lovingly referred to, does not belong to your app. If you try to touch it directly, you'll get a segmentation fault at almost any address:

int main(int argc, char **argv) {
         char *p = (char *)0x70000000;
         *p = 'a';
}

This range of memory is set aside for times when the OS needs to map data into your address space. This happens when writing directly to the frame buffer, for instance. These locations may be in existence before you explicitly request them, but you should never try to guess where they live.

The lower half of the address space also contains everything used by the kernel, including kernel code, kernel data, kernel heap, driver code, disk and loader cache, physical memory, and various buffers needed to communicate with the hardware. The reason why the whole kernel is always mapped is that this allows you to enter the kernel without doing a context switch (you just need to switch the protection level).

At 8 bazillions, your application's code and data lives. When using the listarea command, these are referred to as seg0 and seg1, respectively. The heap, where dynamically allocated memory lives, immediately follows the data segment.

Add-ons are loaded at 0xea000000. You'll find translators, Tracker add-ons (if you're examining Tracker memory), and so forth here. Note that because they run in your app's team and memory space, misbehaved add-ons can crash your application.

Libraries are loaded at 0xec000000. libnet.so and libroot.so will always be present, in order to give basic functionality and to ease recompiling of UNIX programs. In addition, you'll typically link against libbe.so and others.

The stacks for your various threads live at 0xfc000000. In R4.5, the main thread has 2 megabytes of stack, while other threads have 256k. In the next version of BeOS, the main thread will have 16 megabytes of room, which is needed for demanding applications like gcc.

If your application contains a BApplication, as most do, you'll also have some data mapped in from your connection to the app server, at 0xd0000000. This code

#include <Application.h>
#include <Bitmap.h>
#include <stdio.h>

int main(int argc, char **argv) {
         BApplication app("application/x-vnd.BeDTS-BitmapTest");
         BRect rect(0, 0, 639, 479);
         BBitmap *bitmap = new BBitmap(rect, B_RGB32);
         uchar *bits = (uchar *)bitmap->Bits();
         printf("Bitmap at %p, bits at %p\n", bitmap, bits);
         delete bitmap;
         return 0;
}

gives this:

Bitmap at 0x80009a80, bits at 0xd0000440

Notice that the bitmap object, being new'ed, lives on the heap, whereas the image data itself is in rw server area. There are also read only and global read only regions of memory from the app server which contain things like the system palette.

Lastly, you'll find net server memory located at 0xa0000000. Information about your sockets and the buffers received by the net server itself reside here.

The clichés are familiar: Comdex is terrible, crowded, tasteless, useless; Las Vegas is terrible, crowded, tasteless, etc. And the portions are too big. There must be some truth in the litany when cab drivers (one a very knowledgeable and articulate former Intel employee) complain that attendance is down by more than 10%.

Attendance at the Be booth in the Sands did not reflect the slump, however. This year, more than ever before, the crowd spilled over into the aisles and the booth opposite ours. Comdex organizers came and admonished us to control the situation. We apologized profusely and tried to keep the aisles and the neighboring booth clear. For next year, we've reserved a larger, more conveniently located booth, and we'll make more room for the audience.

We demo'ed BeOS in both desktop and Web appliance applications. We showed the first public demonstration of the National Semiconductor WebPAD running BeOS. The 2.4 Ghz wireless Ethernet served the tablet form factor well; visitor reactions confirm that this is a promising direction. Combine instant-on, broadband connectivity; seductive multimedia performance; and extemporaneous, untethered Web navigation—and you have a user experience that's attractive to hard core technophiles and reluctant technophobes alike.

Of course, we felt "validated" when Bill Gates decreed Web appliances official. A little nervous, too, because, once again, we're competing on a field that Microsoft is targeting. No real surprise, but a reminder of the giant's known appetite.

Because of our IPO's all-consuming schedule, I hadn't seen Jerry Basserman in action at PC Expo. I had seen him in another capacity, celebrating a wedding—not in Las Vegas, I'll hasten to add. At Comdex, on more mundane matters of operating systems and applications, he was no less evangelistic. He led the crowd through a review of BeOS features and applications such as Moho, Gobe, Easel, 3dmiX, and personalStudio. For a finale, he literally pulled the plug to prove the robustness of the file system and the boot speed.

But there was more to our booth and our demos than larger, enthusiastic crowds in a less-attended than usual Comdex. There was more than a growing number of applications, or visitors telling others, as I overheard: "See, that's what I've been using for over a year...." What's new this time is a different sense of possibilities. In the past, I've often heard: "Cool demo, but...." I'll let you finish the sentence. This year, for reasons ranging from progress on our product and applications to a possible power shift in the industry and to the emerging wave of Internet appliance applications for BeOS, there's a sense that alternative OSes have an important role in the future of our industry.

That said, we still have a lot to do and a lot to prove. I'll conclude by giving thanks to all who made this successful Comdex possible, from application developers, to contractors, to the many individuals at Be who organized and performed so competently. Happy Thanksgiving!