Or rather, how to use MIDI on the BeOS and, of course, OpenBeOS. 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 (located at http://www.borg.com/~jglatt/), and of course www.midi.org.

At this time of writing, the OpenBeOS Midi Kit is not finished yet, but you can already start experimenting under BeOS R5. After all, both kits will be binary compatible, so when OpenBeOS is finished, it can run your MIDI apps without any problems.

The two kits

The BeOS actually comes with two different, but compatible Midi Kits. This article focuses on the "new" Midi Kit that was introduced with BeOS R5. The old kit, which we'll refer to as midi1, is more complete than the new kit, but less powerful. Both kits let you create so-called MIDI endpoints, but the endpoints from the midi1 kit cannot be shared between different applications. The midi2 kit solves that problem, but unlike midi1 it does not include a General MIDI softsynth, nor does it have a facility for reading and playing Standard MIDI Files. Don't worry: both kits are compatible and you can mix-and-match them in your applications.

The old kit is pretty well documented in the BeBook (go here: http://bang.dhs.org/be/bebook/The%20Midi%20Kit/index.html), but the new kit unfortunately isn't. For the time being, you can find preliminary midi2 documentation at the OpenBeOS Midi Team website (located at http://home.concepts.nl/~hollies/midi/midi2.html). I suggest that you read through it, especially the introduction (here: http://home.concepts.nl/~hollies/midi/midi2intro.html). In the future, we will clean up the docs and move them into the OpenBeOS source code tree where they belong.

Endpoints and the roster

The purpose of the midi2 kit is to manage MIDI endpoints. An endpoint is like a MIDI In or MIDI Out socket on your equipment; it either receives information or it sends information. Endpoints that send MIDI events are called producers; the endpoints that receive those events are called consumers.

If your sound card has a MIDI port, for example, then the midi_server (which does all the behind-the-scenes work for the midi2 kit) publishes a consumer and producer endpoint for that port. But an endpoint doesn't necessarily have to correspond to a hardware device; you can also make filters that process and modify MIDI events before passing them on. The source code that accompanies this article demonstrates how to build such a filter.

Central to the midi2 kit is the Midi Roster, which allows you to find available endpoints, and publish your own endpoints. It also lets you make and break connections. Your applications will use the roster to create networks of MIDI objects, and stream MIDI events between them.

If you want to see which MIDI endpoints are currently available in your system, download PatchBay (here: http://home.concepts.nl/~hollies/midi/samplecode.html) or PatchStudio (here: http://www.bebits.com/app/1979). These applications show all the available endpoints, and provide a convenient interface for connecting and disconnecting them.

Echo..o..o..o..

To demonstrate how to program the midi2 kit, I have constructed EchoDemo, a simple application that adds echoes to all incoming notes. You can download it at http://openbeos.org/samples/EchoDemo1.zip. In other words, it plays the same note several times in a row, each a little softer. The app doesn't look like much, but it does touch on most of midi2 kit's capabilities.

EchoDemo publishes a consumer endpoint and a producer endpoint. This combination of a consumer and a producer is commonly called a filter. The consumer receives incoming events, the filter processes them, and finally the producer sends out the filtered events. In our case, the filter sends out extra notes for every "note on" event.

EchoDemo's window contains two list controls: the one on the left shows all the producer endpoints that you can hook up to the filter's input, and the one on the right lists the consumers that you can connect to the filter's output. Simply click in a list to connect a producer or consumer; hold down Shift to connect multiple endpoints. The window also contains two sliders that let you set the number of echo notes and how much delay there is between these notes.

A filter by itself is pretty useless, so you need two extra applications to play with EchoDemo. I suggest you hook up Midi Keyboard (here: http://www.bebits.com/app/1808) to the filter's input and InternalMIDI (here: http://www.bebits.com/app/2201) to its output. That way you can play notes on the virtual keyboard, the filter will add echo notes, and InternalMIDI will play back everything using the General MIDI softsynth.

For even more fun, load up PatchBay and notice that its window now also shows the filter's input and output endpoints. Also notice that if you use PatchBay to connect endpoints to the filter, EchoDemo's list views automatically update their selections. The roster notifies midi2 applications about such changes, so they can update their screens in real time.

Time's up

That's it for now. Rather than repeating most of the source code here to explain how EchoDemo works, I made the source speak for itself. I have tried to keep things as simple as possible, and added comments to most of the tricky stuff. Don't forget to read the midi2 kit documentation located at http://home.concepts.nl/~hollies/midi/midi2.html as well.

OpenBeOS x86 boot process specification
Creation Date: November 23, 2002
Version: 1.0 (Nov 25, 2002)
Status: preliminary proposal
Author(s): Axel Dörfler

OpenBeOS will use a boot loader process with 3 different stages. Since the second stage is bound tightly to both other stages (which are independent from each other), is referred to as stage 1.5, whereas the other stages are referred to as stage 1 and 2.

The following will explain all stages in detail. Note that this document is not necessarily complete and a work in progress - it doesn't describe a situation as-is, but one that very likely will be.

Stage 1

The first stage is responsible for loading the real boot loader from a BFS disk. It will be loaded by the Master Boot Record (MBR) and executed in the x86 real mode. It is only used if the system will be booted directly from a BFS partition, it won't be used at all if it is booted from a floppy disk or CD-ROM (in this case, stage 1.5 is in charge immediately).

It resides in the first 1024 bytes of a BFS disk which usually refers to the first two sectors of the partition in question. Since the BFS super block is located at byte offset 512, and about 170 bytes large, this section is already reserved, and thus cannot be used by the loader itself.

The MBR only loads the first sector of a partition into memory, so it has to load the super block (and the rest of its implementation) by itself.

The loader must be able to load the real boot loader from a certain path, and execute it. In BeOS this boot loader would be in "/boot/beos/system/zbeos" - this name will likely change for OpenBeOS, though.

Theoretically, it is enough to load the first few blocks from the loader, and let the next stage then load the whole thing (which it has to do anyway if it has been written on a floppy). This would be one possible optimization if the 850 bytes of space are filled too early, but would require that "zbeos" is written in one sequential block (which should be always the case anyway).

zbeos (or whatever it will be called)

Contains both the stage 1.5 boot loader and the compressed stage 2 loader. It's not an ELF executable file; i.e. it can be directly written to a floppy disk which would cause the BIOS to load the first 512 bytes of that file and execute it.

Therefore, it will start with the stage 1.5 boot loader which will be loaded either by the BIOS when it directly resides on the disk (for example when loaded from a floppy disk), or the stage 1 boot loader, although this one could have a different entry point than the BIOS.

Stage 1.5

Will have to load the rest of "zbeos" into memory (if not already done by the stage 1 loader in case it has been loaded from a BFS disk), set up the global descriptor table, switch to x86 protected mode, uncompress stage 2, and execute it.

This part is very similar to the current stage 1 boot loader from NewOS.

Stage 2

This is the most complex part of the boot loader. In short, it has to load any modules and devices the kernel needs to access the boot device, set up the system, load the kernel, and execute it.

The kernel, and the modules and drivers needed are loaded from the boot disk - therefore the loader has to be able to access BFS disks. It also has to be able to load and parse the settings of these drivers (and the kernel) from the boot disk, some of them are already important for the boot loader itself (like "don't call the BIOS"). Since this stage is already executed in protected mode, it has to use the virtual-86 mode to call the BIOS and access any disk.

Before loading those files from the boot disk, it should look for additional files located on a specific disk location after the "zbeos" file (on floppy disk or CD-ROM). This way, it could access disks that cannot be accessed by the BIOS itself.

Setting up the system for the kernel also means initalizing PCI devices needed during the boot process before the kernel is up. It must be able to do so since the BIOS might not have set up those devices correctly or at all.

It also must calculate a check sum for the boot device which the kernel can then use to identify the boot volume and partition with - there is no other reliable way to map BIOS disk IDs to the /dev/disk/... tree the system itself is using.

After having loaded and relocated the kernel, it executes it by passing a special structure which tells the kernel things like the boot device check sum, which modules are already loaded and where they are.

The stage 2 boot loader also includes user interaction. If the user presses a special key during the boot process (like the space key, or some others as well), a menu will be presented where the user can select the boot device (if several, the loader has to scan for options), safe mode options, VESA mode, etc.

This menu may also come up if an error occured during the execution of the stage 2 loader.

Christmas in my house is a time of giving and sharing. A time to reflect on the nature of the season, a time to be with your family, a time for togetherness and joy. Oh, and presents.

This year, I decided that I would buy my wife a new computer and that the children would receive her old computer as a "hand-me-down". I set about designing a new system that would meet my wife's needs. She is an avid web surfer, including VRML based chat sites, plus email and light word processing. No Quake 3, but some level of 3D performance would be a good thing. I decided on an Asus A7N266-VM motherboard. Integrated video, sound, LAN, everything on board, at a low price. Yes, the graphics performance isn't earth shaking, but for her light needs, it is suitable. An Athlon 1700+, a Western Digital 80GB 7200RPM 8mb cache hard drive and 256mb PC2100 DDR Ram filled out the machine. Oh, and a CD-RW - $50 - unbelievable how cheap they are!

The next issue is an operating system. Yeah, I know that it should be R5. But the lack of certain software makes that impossible. Plus, I had a copy of Win 2K that I bought for a consulting job just lying around. So I built the machine, fired it up and it booted on the first try! Woot! Everything was going so well. Then I had to ruin it. I opened the CD-RW and put the Win2K CD in.

First things first, we have to format the hard drive. Not unexpected, but slow. Minutes and minutes slow. I would have thought that a nice, clean, fast drive should format very quickly. No such luck. Still, it is a point in W2K's favor that it handled it transparently for me; the process was very simple. Now we can install the OS itself. Another painfully slow process, but without too many tribulations. A quick reboot, log in as Administrator and there we are. Change the resolution to something reasonable, create an account for normal use and we seem to be good to go.

Then the pain starts. Since this is a Windows 2000 CD, and it was almost 2003, I figured that there would be some updates. All very nice, so I go to Windows Update. Let the pain begin. There were 13 critical updates. But some of them had to be downloaded and installed alone. I selected as many as I could and downloaded. This was a 20 mb package! Fortunately, I have a cable modem, so it took maybe 5 minutes or so. Download complete, time to reboot. OK, log in, wait, go to Windows Update. More critical patches. Download those. Another 25 mb file. 5 more minutes. OK, reboot. Log in, wash, rinse, repeat. 100mb and 2 hours lated, all of the patches to bring the machine up to date were complete. As I was doing this, I realized that all of the software that came with R5, put together, was less than this "upgrade". Uncompressed.

Would it have been so tough for the installer to at least download all of the critical patches together? Even if you do have to reboot in between. Which seems sort of unusual to me, but their architecture requires it. I had to sit and babysit the machine. It couldn't just "do its thing" and be ready when I came back. I had to be there to log in and pick some more updates. This is poor design.

Now, with the machine running "modern" software, I start looking at devices. Turns out that the USB printer and scanner didn't get recognized. Of course, it was only by *not* seeing them that I knew that they were not recognized. It would have been nice to get some indication that the devices were seen, but that no drivers existed.

One of the criticisms of BeOS is that "my hardware wasn't supported". I think that this is one of the more unfair issues. The underdog in the OS market has a terrible onus - since they aren't big enough for manufacturers to support, they have to support every manufacturer. I certainly understand why that is. But the conditions make it hard to be a small OS company. In this case, though, Windows didn't support my hardware either. I had to go to the companies' website and, in one case, to a third party since Win2K wasn't supported. Not as different from BeOS as some might think. I have to point out, though that many newbies couldn't do this. The drivers on the disks/CDs that came with the hardware didn't have Win2K drivers. A newbie might have just been stuck.

The final tale of Windows Woe came from helping out a friend. His PC died a horrible death and he had no money for a new one. I had an old Pentium Pro machine running RedHat7 that I had forgotten the root password to and didn't need, anyway. It hadn't been plugged in for over a year and, well, it was Christmas. So I gave him the machine. He called me from his home to ask my how to reformat the drive so he could load a Windows CD that he had for the dead machine. An hour on the phone and wrestling with fdisk brought me to the conclusion that Linux does things to the disk that fdisk didn't know how to handle. Sigh. I was googling for answers and found a web site of fdisk that had a "what to do if deleting partitions doesn't work" section. They pointed to someone else's web site that had an assembly language program and step by step instructions for debug.exe to wipe the partition table. I read it over the phone to someone who had never written a significant line of code in his entire life. Success! The partition table was wiped. The repartitioning and formatting went absolutely normally after that.

So... what is the point of all of this? How does this relate to OBOS? Harvey Mackay, a great business writer and CEO of a successful company wrote "I always do the hiring for just two slots: President and receptionist." OK, President makes sense. But why receptionist? Why? "the first significant impression of the company is from the receptionist/switchboard operator." In the same way, the first thing that any intrepid person who ventures out to try a new and strange (to them) OS is the installer. In the first case, while the installer worked, it was mind numbingly slow and tedious. In the second case, only a total guru could have fixed the problem. Neither of these can be acceptable for us. Our installer has to *far* surpass the Windows installer or people won't even finish the install. Once the install is complete, though, upgrades (again, OS installer) can not be as painful as a root canal. We have to be respectful of people who might be upgrading via dial-up (oh - Microsoft will sell you an upgrade CD for the low, low price of, what, $15?). Upgrades have to be fast to download and easy to install. You should be able to install all of the current upgrades at once. And rebooting is forbidden except in extreme circumstances.

You only get one chance to make a first impression. I believe that we are in the "sweet spot" for people's recollections. A couple of years ago, people might have said "I tried BeOS and {fill in the disaster}". A couple of years from now, people might say "yeah, that was good in its time", much like they do with the Amiga today, right or wrong. We need a solid base hit to make a good impression. And the installer is the first step on the way to that solid base hit.