While there is a vast variety of styles of programming, there are essentially only two styles of debugging. Some programmers prefer to pepper their code with hundreds of printf() statements rather than ever using a symbolic debugger (Benoît Schillings, the author of our Application Server, is foremost among these); others scoff at such scaffolding, morally convinced that printf() debugging is the height of inelegance. Most application writers use a combination of both, depending on the task.

With the advent of the GUI and window-based applications, printf()-style debugging naturally became harder. Where does debugging output go for applications not launched from a shell? Currently, the only solution in the BeOS is to make sure that serial debugging output is enabled and that you use the SERIAL_PRINT() call to see your messages on an attached terminal. In the unfortunate circumstance where you don't have a spare serial terminal, you're plumb out of luck. You have to fashion another method of saving your debugging output.

Even for programs launched from the shell, viewing debugging messages from within the shell can get very confusing. For one, debugging messages can get mixed up with real program output. Furthermore, in a multithreaded application, unless the application writer goes to great lengths to record the thread ID in every message, making sense of which thread spit what out can give you a migraine.

As a solution to some of these problems, DR9 of the BeOS will include a "syslog_daemon," which provides the facility to log messages of all sorts —from applications, servers, and the kernel—to a file. By default each message gets a time stamp; the daemon can also log the caller's thread ID and an identifier string. Furthermore, each message can be given a priority.

For example, simple, informational debugging messages should be given the priority LOG_DEBUG; more critical messages, such as severe errors or application panics, should be given a higher priority, such as LOG_ALERT or LOG_PANIC. Developers can then set a preference for which priority messages they want to log. If you're interested only in severe errors, for example, you wouldn't want to be bothered by ordinary debugging messages.

As the name suggests, the syslog_daemon is inspired by a similar service in the UNIX world. syslog_daemon is a simple Be application that sits waiting for Be messages and conditionally writes them to a file, serial port, or the standard error stream.

The API for using syslog_daemon is identical to its UNIX counterpart, except for multithreaded extensions. Here's an outline of the routines:

• openlog_team and openlog_thread set up default logging behavior. They take the arguments: (ident, options, facility).

• log_thread, log_team, and syslog take printf()-style specifiers and fire a message off to the syslog_daemon. They take the arguments: (options, format string, ...).

• setlogmask_team and setlogmask_thread set which messages to mask on a priority basis. They take the argument: (prioritymask).

• closelog_team and closelog_thread end a logging session.

• logger is a command-line routine to use in shell scripts.

The routines are grouped by team or thread, because it's sometimes desirable to report messages on a per-team basis rather than on a per-thread basis. The bare routines openlog(), syslog(), setlogmask(), and closelog() default to the per-thread functions.

The openlog calls are optional; if the program doesn't call openlog itself, the first call to the logging routine will implicitly call it. Openlog just allows the programmer to set up default options (such as thread ID logging, serial port output, and so on) and an identifier string for all logged messages from the thread or team. "Facility" is a predetermined classification used by the syslog_daemon; facilities include the kernel, user programs, servers, the syslog_daemon itself, and so on.

The log_thread, log_team, and syslog() functions are the moral equivalents of printf() and accept all the same specifiers.

The messages are logged as follows:

Feb 13 13:14:49 'ftpd'[145]: received 1000 bytes
Feb 13 13:15:01 'thread1'[200]: got here! yeah!
Feb 13 13:15:05 'thread1'[200]: Waiting on semaphore foobar
Feb 13 13:15:07 'thread2'[201]: Waiting on semaphore foobar

Currently, all messages are logged in a single system-wide file. Ideally, I'd like to set up the ability for each application to optionally specify a different log file, but it's unlikely that I'll have that finished for DR9. I'm also planning a reasonably nice Log Viewer (a la Event Viewer on Windows NT), which will allow users to view and sort messages according to various criteria.

This, along with the debug_server enhancements and fixes that are also going to be in DR9, should make both styles of debugging in the BeOS a whole lot more pleasant. If you'd like to offer further ideas as to what would make your life easier, please don't hesitate to send me e-mail at mani@be.com.

The Media Kit provides direct access to the buffers used by the built-in analog-to-digital converter (ADC) and digital- to-analog converter (DAC) on both BeBox™ and Macintosh computers. Because the audio hardware is shared between applications, the audio data format of the buffers must be the same for all applications that are using the hardware at one time. Here are some suggestions for applications that want to play well together.

We strongly recommend that you run the ADC and DAC streams in 16-bit stereo mode. Fortunately, it's easy to convert between 8-bit and 16-bit and between mono and stereo formats. 16-bit stereo is the only format supported by the standard Macintosh hardware.

We also recommend that, if possible, applications support a sampling rate of 44.1 KHz. If it's necessary to do processing at 22 KHz, then 44 KHz input can be downsampled to 22 KHz by taking every other sample, and 22 KHz can be converted to 44 KHz by filtering or interpolation. Linear interpolation may be sufficient.

To lead the way in following this advice, I dusted off an old application I sometimes use to test the audio streams. The Laserbreath application is a linear-phase bandsplitter with an adjustable time delay applied to each band. My 66 MHz BeBox isn't fast enough to process many bands at 44 KHz stereo, so I modified the program to do its processing at 22 KHz and to use linear interpolation to output at 44 KHz. The application with source code will be posted as sample code on the Be ftp site (ftp.be.com).

The Laserbreath application uses a Nino object (described in Be Newsletter #36) to connect the ADC stream to the DAC stream and does it's processing in the DAC stream. To use it, feed an audio source into the ADC, mute the loopback control, and listen to the DAC output.

There are two rows of (very simple) sliders. The top row controls the level of each band, like a graphic equalizer; the bottom row controls a time delay for each band. The bands are equally spaced, having higher resolution at high frequencies and lower resolution at low frequencies than a typical graphic equalizer, whose bands are octave spaced. This type of bandsplitter is more applicable to noise reduction than to equalization. The name Laserbreath probably comes from the swooshing sound produced by the default setting for the delays.

The bandsplitting algorithm used is quite elegant and is described in and article by J. A. Moorer and M. Berger, "Linear-Phase Bandsplitting" (J. Audio Eng. Soc., Vol. 34, No. 3). The input is fed into a comb filter, so called because its frequency response curve looks like a comb, with many sharp zeros of transmission. If the input samples are X[n], then the comb filter output is C[n] = X[n] - X[n - P], where P = (2*nB - 2) and nB is the number of bands to be split. The zeros of transmission of the comb filter occur at wavelength which evenly divide P samples which correspond to frequencies which are multiples of Fs/P where Fs is the sampling rate. The output of the comb filter is sent to a parallel bank of resonators (implemented as second-order recursive filters). Each resonator has a resonant frequency corresponding to one of the zeros of transmission of the comb filter, and its output passband is centered around that frequency.

The outputs of the bandsplitter are the same as you would get if you computed an FFT for each input sample. Because the input to each successive FFT differs only by adding one sample at one end and removing one sample at the other, the computation can be reduced to the recursive form used here.

So for once I'm not going to be long-winded.

Most of the time when I hear my daughter speak, I can understand what she's trying to convey. Whenever someone else listens, they don't necessarily get the message, because a 21-month old doesn't really have a firm grasp of the language yet. Her message is garbled, but we go over it again and again until her words are crystal clear and we're communicating.

There's quite a lot going on with Be right now, and you should be hearing good news about various licensing agreements, marketing plans, distribution opportunities, and the like. We'll try to make our plans crystal clear, and you shouldn't have to strain to get our message. So I'll say it again here for reference: For this year, our plan is to get apps out there on a stable OS that will be very prolific.

To this end, we want to support our developers as much as possible in getting up on the current release as well as getting to DR9 as quickly as possible. Applications written for DR8 will not be binary-compatible with the DR9 release, thus developers will have to recompile their code and make some modifications in order to take advantage of new functionality.

Needless to say, we want as many apps available on DR9 as soon as possible. We have mentioned a couple of times our desire to host a porting lab. Thus far the response has been positive. Now, we'll get more formal about it. If you want to participate in a porting lab, then please send a message to devservices@be.com. The lab will be held in mid to late March, and as the date approaches, we'll get more specific. But since we expect this space to be limited and in high demand, you'll want to at least sign up now.

This lab is intended for developers who intend to ship a product that is for purchase with DR9 and for whom timing is critical. If you have a product that's for your own use and don't mind waiting a few weeks, then you shouldn't come to this lab. The lab will be on-site here at Be and will be available for a two week period.

Another near-term event is the Developer's Conference, which will be held around the same time as the World Wide Apple Developer's Conference. May 10 and 11 are the tentative dates here in the Santa Clara Valley. We'll be presenting a number of topics primarily related to getting to DR9 and the future of the BeOS. A two-day event is scheduled with an emphasis on getting your code working. We're planning a number of introductory and advanced sessions in which there is some lecture and discussion, and we'll make available a number of machines for developers to actually write code on.

We want this to be a very interactive, participatory event, so we won't try to usurp your time. We also want developers to be involved personally, so we'd like to hear from you as to any particular topics you want covered. We already have an agenda that covers most of what DR9 is going to be, but we'd like to take topics from you as well. We'd also like to give you the opportunity to give a presentation yourself if you have expertise in a particular area. If you think you'd like to give a presentation at the conference, please send e-mail to hopwood@be.com. Michael Hopwood is our Product Manager and Evangelist and is coordinating this conference. He'd love to hear from you.

This week finds us in both Tokyo and Paris. Big announcements, lots of demos, lots of code being written. The BeOS is a fun place to be, and looking more lucrative every day. You'll see reports on both of these events over the coming weeks.

So like I said, GCC has been ported to the BeOS by Fred Fish. This guy is totally amazing and has done a ton of work in getting standard GNU utilities supported on our platform. To begin rewarding his efforts, we're going to include a lot of his work into the DR9 release. GCC in particular was used to compile a number of the utilities. Don't start asking questions about whether this means we support Objective-C and whether you can use g++ with Metrowerks code. The answer is, you can use gcc to compile the GNU non-UI, non-C++ utilities, and that's about all we're going to support. We won't include the gcc compiler as part of the system, since it would just cause confusion as to which tools are truly supported, but it will be darn easy to get it and install it.

Along the same lines of incorporating developer code, we're also including the DataTypes library from Jon Watte of Metrowerks. As mentioned oh so many moons ago, this library allows for the easy translation of datatypes in any application, without the developer writing specific code for all data types. Our very own Hiroshi Lockheimer has incorporated Styled Text into DR9 as well. So, that's the way things go. Developers work their hearts out to promote an OS, and they're rewarded with positive and appreciative responses from the OS vendor. Isn't that the way it works with all OS companies?

If I can't write next week's article within the next 12 hours, then you'll get a break from me for a week, so until then, get back to coding so we can show off your stuff!

This is a magazine I highly recommend to anyone interested in the Net and to anyone who's tired of the bland and predictable prose you'll find in magazines published by corporate giants. A little history will explain, perhaps, why I like and recommend—two distinct notions—this monthly publication.

When we started Be, one of our key goals was to link our customers, our developers, and ourselves in one community. This was in early 1991, when we were writing the first Be business plan. We wanted customers to register on-line, so they would receive weekly e-mail notifications of bad news (more bugs found) and good news (more applications available). We also wanted customers to tell us swiftly what they hated and, perhaps, what they liked. Just as important, we wanted developers to market and deliver their software on-line, promoting their wares on our bulletin board, offering demos as well as full versions, bug fixes, new releases, helper apps, the works.

I wrote "bulletin boards." They were the rage at the time. There was a very large community of bulletin board systems developers and users. Some ran on Macs, with an exceptionally good one deservedly called FirstClass. Most worked on cheap (I mean inexpensive) PCs, with software from companies such as Galacticomm, eSoft, or Mustang, with geeky multiport boards and networks to string the PCs together if you scored more subscribers. At the time, companies such as MacAfee were doing a brisk business selling anti-virus software with such systems, roomfuls of PCs on Novell networks. From the two or three BBS magazines in existence at the time, one was clearly the leader, Boardwatch, and it organized a convention, BBSCon. So we went there (it was held in Colorado Springs in '92) to check companies and products. Quite a scene if you'd lived too long in the Apple cultural framework; an exciting one if you were looking for action. The famous Star Wars bar scene came to mind with all sorts of mutants speaking in tongues and big beer bellies stretching t-shirts reading "Windows is for sissies." Geek heaven.

So I kept reading Boardwatch, I subscribed, got on their own BBS from my Windows machine, and logged onto the many FirstClass systems worldwide from my Mac. We even thought it would be exciting to bundle a Be version of FirstClass with each system we'd sell, your own personal server. This was before the Internet came out of UNIXdom.

My liking and respect for Boardwatch grew even stronger when I saw the magazine take to the Internet and the Web. Jack Rickard, the editor, reacted sooner and faster than Bill Gates. Today, it's the Internet magazine to read if you want information and opinion unmitigated by corporate minions and focus groups. Jack Rickard writes what he wants, answers reader mail any way he wants, and the result is informative and liberating. I have yet to read someone who understands the technology and the games being played as well as he does. Eons before anyone in the trade, Boardwatch had great HTML tutorials, and when Windows 95 came out, it was the only source of non-PR information on Win95 networking. Great discussions of legal issues as well, more competent than in the general computer press, politically on the "leave us alone" side of the aisle and honest about it.

http://www.boardwatch.com, jack.rickard@boardwatch.com.

Enjoy!

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.