Compile them resources

Body

All BeOS programs have "resources". Simply put, a resource is data that is bundled with your application's executable. Typical examples are the application's icons and its signature, but you can attach any data you want. Many applications store bitmaps, text, cursors, and even complete user interfaces (dialog boxes, menus, etc.) as resources.

This may sound a lot like attributes; after all, aren't attributes a way to store additional data alongside your files as well? Yes, but the difference is that resources can only be used with application files, not with just any file. Unlike attributes, they are not intended as general purpose data storage. Instead, they only provide data that "sticks" to the executable. Although applications can overwrite their own resources, this is not recommended. Resources are typically set during compile time and never change afterwards. This means, for example, that you should not use resources to store user settings.

Introduction to MIDI: Part 2

Body

This second part of my introduction to MIDI programming on (Open)BeOS is about timing. If you read Part 1 and tried out the demo app, you may have noticed that playback of the notes really lagged behind if you quickly pressed several keys in a row. That is bad, because we want MIDI processing to be as real-time as possible. This article explains where the lag comes from, and shows you how to prevent it. Be warned: some of this discussion goes into gory low-level details and the guts of the Midi Kit, but that is the price you pay for low latency MIDI performance. Actually, it ain't all that bad.

Introduction to MIDI: Part 1

Body

Or rather, how to use MIDI on the BeOS and, of course, Haiku. MIDI stands for Musical Instrument Digital Interface and is a well-established protocol for controlling musical devices such as keyboards, synthesizers, drum computers, and a whole bunch of other stuff. The protocol is fairly simple and consists of commands such as "play this note" and "now use this instrument". You don't need to be a MIDI expert to write BeOS MIDI apps, but some knowledge of the protocol helps. I won't go into the MIDI protocol in this article, so you may want to check out the MIDI Technical Fanatic's Brainwashing Center, and of course www.midi.org.

Experiments in Scheduling

Note: this article was written by Daniel Reinhold who unfortunately left the Haiku project and thus doesn't have his own website account.

The OS scheduler is the heart (nearly literally) of any operating system, so it's got to be in good working order. It needs to be fast, efficient, and distribute the computer's resources fairly. But what does that really mean? What makes a good scheduler?

In order to better understand this critical component, I recently wrote a userland prototype that mimics a real scheduler. This is taking advantage of the 'friendly third option' in kernel development. That is, when you want to test (and/or otherwise examine) a piece of kernel level code, you either:

A crash course in inline source code documentation with Doxygen

Body

So I'm sure a number of you out there were a bit skeptical as to whether or not I'd be able to churn out two Doxygen newsletter articles in a row (I sure didn't think I'd manage :). Well, just to spite all of us non-believers, here I am with a shiny new tutorial on documenting your source code with Doxygen. The things I'm going to cover here are just the basic meat-and-potatoes parts of Doxygen that I use on a day to day basis; for anything else, please consult the online Doxygen manual; it's really quite handy :).

Pruning the / tree

Body: 
*** Warning - this editorial may contain concepts and ideas disturbing to Unix purists!***

First, let me start out by stating that I use Unix (Solaris) almost every day. While I am not the master of all things Unix, I have a better than average knowledge of it, I like to think. I like a great many things about Unix. Pipes are probably the most useful concept I have ever seen in computer science. It is componentization of software some 20 years before it came into vogue.

I Will Survive

Body

It's not something that might happen in a rare circumstance, something that can be neglected in the design of your media application, but something that will happen as soon as the user hits that big inviting button on front of the Media preference panel - the media_server quitting while you rely on it and the connections you have established with your own and other media nodes. So, for your programs to survive this situation, is quite desirable. And, of course, Soundplay taught us first - it can be done!

Some vague ideas...

Body: 

Late at night, beating my brains for yet another newsletter article, my eyes were drawn to a notebook nearby my desk. This notebook contains my ideas that I brainstorm for future versions of OBOS. One of the complaints that people have is that R1 as we have defined it has no "future". It doesn't do anything beyond recreate what Be did and that we should aim higher for our first release. Interestingly enough, there is another, equal sized crowd of people who say that we are trying to do the impossible. In either case, R1 will be what it will be.

Unit Testing, Part Deux

So, I'm sure you're all dying to know about the new grand unified CppUnit testing framework we have. What? You haven't heard of it? Color me unsurprised. :-)

Part I — Running Tests

For those of you who are purely interested in helping us out by running the tests on your own computer, this section is for you.

First off, you'll need to slurp a copy of our repository onto your computer. Next, you'll need to build the entire tree (technically you don't need the *whole* tree, but it's easier on me if you just build it all; that way I don't have to list off all the targets you'd need to specify :-). For those who are unsure of how to do this, get a copy of our development tools off the Download page, do an anonymous checkout of our repository (check out Getting and Building the Haiku Source Code for details), run ./configure from the current/ directory, run jam from the current/ directory, and go watch The Godfather (possibly all three of them) while everything builds.

Optimization can be your friend

Body

Optimization is one of those topics that everyone thinks that they understand a little about, but is often surrounded by platitudes, mystery and rumour. I want to talk a little about when to optimize, why one should optimize and some of the more successful techniques of doing so.

Keep it simple

The first rule of optimization is, "Don't". As Extreme Programming says, "Do the simplest thing that will work". If you are working in an OO language, this is often fairly easy because of information hiding. Design your classes well and hide what you can. Put something together with only a little thought about performance. Test it and see that it works. Then consider your expected use. Many times, an inefficient program *MAY* be acceptable.