|
Be Newsletter
Issue 49, November 13, 1996
Table of Contents
Be Demo Tour: Cornell, MIT, Harvard, Dartmouth
- Monday, November 18, 1996, 2:30 pm to 4:30 pm
BeBox General Demo Meeting
100 Caldwell Hall on the Ag Quad
Cornell University
Ithaca, NY 14853
Directions: http://www.cornell.edu/bin/MapMove.x/M1-1-1?200,300
- Tuesday, November 19, 1996, 6:30 pm
BeBox General Demo Meeting / Boston Be User Group
MIT E51-345
Lecture Hall at the Sloan School (The Business School at
MIT)
Cambridge, MA
- Wednesday November 20, 1996, 4:00 pm
Dartmouth BeBox General Demo Meeting
Carpenter Hall - Room 13
Dartmouth College
Hanover, NH
Carpenter Hall is on North Main Street, about a hundred feet
south of the Kiewit Computer Center
- Thursday, November 21, 1996, 7:30 pm - 10:00 pm
BeBox General Demo Meeting / Harvard Computer Society
Harvard Hall - Room 201
Harvard University
Cambridge, MA
BE ENGINEERING INSIGHTS: The MIDI Sample Player
By Marc Ferguson
According to tiny anthropomorphic hamsters huddled in a
corner at Bloomingdale's pre-opening gala, Be, Inc. will be
releasing its software MIDI synthesizer later this month.
This will allow MIDIphiles to play MIDI files using the
audio output of the BeBox without having to connect to an
external MIDI player. It also provides an easy way for
application developers to add a soundtrack and sound effects
to their applications.
The software synthesizer is based on the wavetable synthesis
engine SoundMusicSys, licensed from Headspace, Inc.
SoundMusicSys was created by Steve Hales and Jim Nitchals
and has achieved considerable popularity among game
developers. The SoundMusicSys engine supports Headspace's
RMF (Rich Music Format), a cross-platform open standard for
musical expression (see www.headspace.com for more about
RMF).
The software synthesizer also supports the General MIDI
Specification, which is a mapping from MIDI program change
numbers to instruments. An application can play ocarina
sounds, for example, by sending a program change number 79
(ocarina) to the synthesizer on one of the sixteen MIDI
channels. The synthesizer will then respond to a note-on
message on that channel by mixing an appropriately pitch-
shifted ocarina sound into an audio stream (usually the DAC
stream).
A high-quality General MIDI instrument sample library was
developed specifically for the BeOS by Peter Drescher of
Twittering Machine Productions. The library includes a
complete set of 127 instruments, plus a percussion bank, and
contains about 5 MB of samples. The instruments are sampled
at 22 KHz, 16-bit resolution. While they're designed to be
able to play a wide range of General MIDI files in a variety
of musical styles, special attention was paid to creating a
lifelike effect from the acoustic instruments.
The SoundMusicSys engine can play user supplied samples as
well as sounds from the sample library; and a selection of
built-in reverb effects can be applied to the samples.
Interested developers should pay close attention to the Be
web site, where a sample application capable of rendering
MIDI files to audio will be appearing, followed shortly by
an API to the synthesizer along with source code to the
sample application.
BE ENGINEERING INSIGHTS: Standard Template Library
By Mani Varadarajan
The next major release of the BeOS, Developer Release 9
(DR9), will include a significant overhaul of our mainline
C++ libraries. Many of these changes should make development
on the BeOS much more flexible. The major new features
planned for inclusion are C++ I/O streams, support for
exceptions, and an implementation of the C++ Standard
Template Library (STL).
Most programmers should be familiar with the first two
features. I/O streams provide an easy way to abstract file
I/O. C++ exceptions provide a mechanism by which the
programmer can handle unexpected or error conditions and
relay them to other parts of the program. Both of these are
described in detail in any good C++ book.
The third new feature, STL, has been a part of the ANSI C++
standard since 1994. STL is a powerful and efficient library
that aggressively uses templates to provide a set of useful
C++ container classes and generic algorithms. These classes
and algorithms provide an easy way to construct and operate
on new and complex data structures.
The details of STL can get rather hairy and may take some
time to understand properly. This article provides a very
brief description of the elements of STL and a few examples
of their use.
STL consists of five elements:
- "Algorithms" are template functions that perform operations
on containers.
- "Containers" are objects that contain other objects and
perform memory operations on them.
- "Iterators" are methods that specify the location of a
container or stream, for use by an algorithm.
- "Function objects" encapsulate functions in an object for
use by other components.
- "Adaptors" adapt components to provide different interfaces;
they translate between classes.
STL extends basic C and C++ programming paradigms, making it
easy to start using the library. For example, STL provides a
generic sorting algorithm, appropriately named sort().
The following code fragment demonstrates how sort() can be
used to sort the elements in a "normal" array, as well as on
the STL "vector" container:
double a[1000];
vector<double> b;
...
// sort all the items in the array
sort(a, a + 1000);
//sort all the items in the vector
sort(b.begin(), b.end());
As with all STL algorithms, the sort() algorithm is generic:
It accepts regular pointers as its arguments, as well as the
STL-defined "iterators" (location specifiers) that are
returned by the begin() and end() calls.
Note that there are various kinds of iterators. The type of
the iterator defines its use. For example, input iterators
provide access to data sources. Output iterators provide
access to data sinks. These can be explored further as the
programmer delves into STL.
The library provides a number of container types. In
addition to arrays ("built-in" containers) and the vector
type demonstrated above, STL provides lists, queues, sets,
and stacks, to name a few. These are all templates, so you
can have a list of ints, set of Employees, and so on,
without doing much work at all.
Here's a simple example taken from the web that once again
uses the vector container type (see
http://www.cs.brown.edu/people/jak/programming/stl-tutorial/tutorial.html
for more examples):
#include <iostream.h>
#include <algobase.h>
#include <vector.h>
main (int argc, char *argv[])
{
int n = atoi (argv[1]); // argument checking removed for clarity
vector<int> v;
for (int i = 0; i < n; i++) // append integers [0, n-1] to v
v.push_back (i);
// shuffle
random_shuffle (v.begin(), v.end());
// print to stdio
copy (v.begin(), v.end(), ostream_iterator<int> (cout, "\n"));
}
This program generates a random permutation of the first 'n'
integers, where 'n' is specified on the command line.
Believe it or not, the algorithm random_shuffle() is defined
in STL.
The last line of this program may be a bit confusing. The
STL copy() algorithm takes three iterators. The first two
specify the source range and the third is the destination.
Here, the third argument, ostream_iterator<int>(), is an
"adaptor." The adaptor converts the integer vector into an
output stream. Assigning to ostream_iterator<int> writes
data out. The two arguments to the ostream_iterator<int>
constructor are the output stream and the element separator.
In summary, STL provides a concise and efficient way of
constructing and operating on a variety of data structures.
What I've presented above are the bare essentials; there are
many other ways these template classes can be used. Look
forward to using them in DR9!
News from the Front
By William Adams
Before I was married, I used to work all the time. Lucky for
me, my future wife worked with me. That's 24-hour-a-day
exposure to my spouse to be!
When we were married, we vowed, among other thing, to not
work on weekends, and not only that, but we didn't keep a
machine at home either. What a time squeeze. At the time we
were doing a lot of NeXT development and were pretty
proficient at it, so things were OK.
Before my daughter was born, I got in the habit of
exercising to think quickly. I figured there wouldn't be
much time to write buggy code accompanied by long hours of
debugging. So, what to do? I know, use frameworks and plug-
ins extensively. Object-oriented programming has been given
a bad wrap. Encapsulation at least is a key development
methodology, which works very well in many situations, and
add-ons implement encapsulation beautifully.
One advantage that the BeOS has as a new operating system,
starting relatively from scratch, is that we have a lot of
good and bad examples to look at. This is true for both the
OS code itself and the applications that we encourage
developers to write. An application like, oh, I don't
know... Lumena, was pretty good, took a long time to
develop, and couldn't keep up with the times.
We can learn from this. We can emulate functions and
features, and best of all, we know what the architecture of
the application should be. I would argue that the
architecture, or framework, upon which the application is
built is one of the most important factors that will
influence how gracefully it ages over time. A framework that
supports add-ons will at least be more easily updated and
possibly more extensible than its traditional monolithic
counterpart. And even at that, we've learned a lot about how
to make add-ons work most efficiently. So like today's OS
that learns from the pros and cons of the past, applications
do the same thing.
As an example, last week I released the first version of
Rraster! This is a simple example of how to support add-ons
using the BeOS. The application is simple, it's meant to be
an add-ons aware image viewer. I would put it in the
category of esoteric software, because although this
particular category has launched such products as Photoshop
and DeBabelizer, this really is a mundane feature that no OS
should be without.
My nanny was deathly ill last week, so I spent at lot more
time with my daughter. When you're with an 18-month old you
don't have a lot of time to think, let alone code. But I had
to stay productive, so what to do? Write more Rraster add-
ons. So this week I've updated Rraster. I managed to add
support for the following file formats:
GIF, PCX, PBM, TIFF, TGA, PNG, JFIF, XBM, and BMP
I didn't quite have enough time for PICT or other Mac
formats, but what can you expect for coding that has to
occur between diaper changes. Then I was about to take a
whack at filter plug-ins and the weekend parties and
visiting started.
You can get the latest at:
ftp://ftp.be.com/pub/samples/translation_kit/obsolete/Rraster.tgz
Of course all this source is for you to be able to write
your own favorite image plug-in and to see how add-ons can
be supported in general.
FROM THE PIT
To continue the deluge of internally developed demo app
source releases, I managed to get Mandelbrot prettied-up. So
take a look at:
ftp://ftp.be.com/pub/samples/graphics/obsolete/Mandel.tgz
You'll see the most often implemented demo code in the
history of graphic computing. This is probably the Hello
World! of graphics programming, other than bouncing balls.
I'll take one more pass at the graphics framework as an
example before moving on to some apps that are more audio in
nature, since we're lacking in this area. Remember, if you
want to see something specific, send in those requests and
keep them coming.
Genre
By Jean-Louis Gassée
In 1987, most pundits started predicting that multimedia was
poised to become the next revolution in computing. I believe
this was the time when the P word, paradigm, as in "paradigm
shift," started to creep into execuspeak. Others felt
multimedia was the simple but important continuation of an
old trend: With great regularity, more of (almost)
everything was offered to hardware and software engineers.
As a result, the computer increased its range of media and,
to a large extent, it handled it more gracefully with the
passage of time.
There was a time when multimedia meant multiple slide
projectors and a tape player; when the multimedia dust
settled for a brief moment before the rise of the web,
multimedia had come to mean a CD-ROM, loudspeakers, color,
music, and animated graphics. At Apple, in the early days of
the new era, we were both clueless and bombarded -- from
outside and, as a result, from the executive suite. We were
clueless because, while we liked more interesting, livelier
computers, at that time we had no idea what the next
multimedia "killer app" would turn out to be. We were
bombarded with suggestions and demands from the outside
world. (This is a long-standing tradition for Apple, one
that seems to perpetuate itself today with suggestions to
adopt a certain operating system.)
For instance, in those days technological haruspices were
clamoring for the adoption of DVI, an Intel-sponsored
asymmetric video compression technology, and there were big
debates about CD-I, the "I" standing for interactive.
Japanese companies were trying to enter the market with a
new kind of multimedia personal computer, the CD-I PC. There
was panic, we must have a statement of strategic direction,
and collateral damage, the overproduction of overhead
transparencies. The search for the multimedia Holy VisiCalc
wasn't going well. Video looked attractive, "compelling" was
the buzzword. Other had their doubts, based on a
combinations of psychological and business arguments. They
saw the classical productivity applications as tools, used
repeatedly and valued accordingly. Video was perceived as
more ephemeral. Captivating, entertaining, but few
customers, if any, would use the same video over and over
again. And for entertainment, why bring TV to the computer
screen?
Sensing the potential, but unable to divine the killer app,
I made a bold move: I hired a childhood friend of Larry
Tesler, Marc Porat, with the mission to scour Apple's
technology portfolio and build a multimedia strategy. He
came up with General Magic instead. But there was hope. One
researcher in Apple's Advanced Technology Group wrote a
short paper summarizing the notion of "genre." The genre
expresses a convention, an agreement combining the
expressive ways of authors and the expectations, the habits
of an audience. The same physical medium can harbor many
genres: Newspaper, book, newsletter, encyclopedia on paper,
or comedy, tragedy, musical comedy on stage. That paper
transmuted the Holy PageMaker question into one of new,
emerging genres. We now know a little more. In many ways,
the CD-ROM has become synecdoche for multimedia, and a few
distinct genres have emerged for the new medium: Games,
reference, software distribution, the questionable
edutainment, and lately, back-up, admittedly not very
multimedia nor totally ROM. All self-respecting PCs now have
a CD-ROM drive, speakers, and reasonable audio and video
capabilities.
The Internet poses even more interesting genre questions. We
have e-mail, news, web pages... E-mail meets the definition
of genre very well: Expectations, audience, expression, the
ingredients are there. The same is true for news. Things get
more confusing for web pages. One can argue company and
personal pages are gaining the stable conventions required
to qualify. But the proliferation of information has created
an opportunity for new genres: Search and delivery.
In a way, General Magic was onto something and investors
were lured by the promise of intelligent agents. Newspapers
use intelligent humans to sort and present information to
us. Humans and computers in concert are likely to create one
or two stable genres mining the web for us and providing us
the combination of the expected and the pleasantly
unexpected, for which we'll be willing to part with some of
our money. Which is another genre criterion.
BeDevTalk Summary
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.
- -----WEEK 2---------------------------
Subject: Fresh Programs
Scripting talk. Correspondents politely debated the merits
of REXX (and OREXX), Java, Python, and so on. At a higher
level, the one-language attitude was questioned: Some folks
would prefer an open scripting architecture, in which any
number of scripting languages are recognized. It was offered
that Be must (at least) standardize the scripting interface
at the application port (AKA socket) level.
- -----WEEK 2---------------------------
Subject: Injecting input into the app_server stream
Methods for polling and calibrating joysticks were
discussed.
- -----WEEK 2---------------------------
Subject: 603e vs DSP
More performance comparisons between the PPC family (the
603e, specifically) and dedicated DSP chips.
- -----WEEK 2---------------------------
Subject: 3D GUI talk
Subject: 3D SPACE
Subject: GUI
More discussion of the possibility of a three-dimensional
desktop. The score so far: Everyone pretty much hates messy
overlapping windows -- anything that can improve this fact
of life is appreciated. 3D, obviously, holds promise in this
area, but most correspondents are a bit skeptical of the
intuitiveness of a full 3D workspace. The provicts argue
that we live in a 3D world, so intuition should be on the
side of a 3D GUI; convicts grant this point, but then score
a right to the jaw by reminding us that our input devices
aren't designed for 3D. (Now, if we had e-gloves...)
A number of counterproposals and fine-tunings were also
offered: "2.5" dimensions, a torus desktop, multiple
(networked) computers connected to the same three-
dimensional workspace, and so on.
- -----NEW---------------------------
Subject: A must Read Article for All
A recent article by Simson Garfinkle in which Mr. Garfinkle
critiqued the Be GUI was met with some beg-to-differism.
After the initial "who does he think he is?" bent, the
thread itself became a constructive criticism of certain
aspects of the GUI.
- -----NEW--------------------------
Subject: Newsletter #48
AKA: Asynch IO
Last week, JLG pointed readers to a couple of articles that
spoke to the Be/Apple rumors. Many correspondents took issue
with the content of one of the articles, in which Gil Amelio
portrayed the BeOS as less-than-real-time and I/O-
challenged. This led to a broader discussion of threads vs
asynchronous I/O.
- -----WEEK 2--------------------------
Subject: BeAPI design flaw? BControl.Invoke() and
A discussion of methods for getting mouse events: Is polling
for mouse movement acceptable? What about blocking in the
main loop while waiting for a mouse move event?
- -----NEW---------------------------
Subject: DR9 Filesystem Features
Many contributors pleaded for an overview of DR9 file system
features. Dominic Giampaolo, the Italian half of Be's
international file system team, complied.
|
