Adam Williams ... Broadcast 2000

Adam Williams is the author of Broadcast 2000, an app which allows you to mix audio and video and looks a little like Pro Tools. If you're mixing audio on a low end pentium or such, one of the nice things you can do is render a succession of tracks with fx in non-realtime and then mix them. There is quite a good range of nice sounding fx that come with it in the form of plugins. Broadcast 2000 is a commercial product available on CD but is also available for free download. To compile it yourself you'll need Linux 2.2.17 kernel, XFree86 4.0.1 and libc 2.1.3 or 2.1.92. And, yup we had a chat with Adam...
related links:
Broadcast 2000 homepage
Commercial sales of Broadcast 2000

> broadcast 2000 must have been a huge amount of work.
> How long did it take you to put the code together?

Adam Williams: General design began in 1997. The first release was finished in 1999. Most of the time was spent in general design and testing. Coding was about 10% of the process. The more you refine your algorithms on paper, the faster the coding happens.

Additional coding time was eliminated by aggressively using C++ and threading. The C++ segments, often regarded as a less pedagogical language by computer scientists, took 1/4 the time to write as the C segments. The C++ shorthand eliminated huge amounts of object initialization, function pointer manipulation, and header file compilation.

Threading offloaded all the concurrency requirements to the operating system, saving another chunk of coding time. Every window is a separate thread. Almost every object is a thread. It fills up your process table, not as elegant as classical signal handling, but it's fast to write.

Beyond having a very high credit limit, there are techniques you use to accelerate application development at the expense of formality. Linux hackers tend to prefer clean build environments, tight programming languages, and classical signal handling, so there's an inflated perception of how complex a program has to be.

> I've only used it for audio and because it works nice
> and efficiently it enables you to do some quite nice things
> on a lower order pentium ... Any plans for expanding the audio
> side? Or giving us some GUI preferences features which will
> allow us to cram more onto a small desktop?

Broadcast 2000 is now right between the low end machines and the high end machines. There are just as many users who expect better utilization of the high end hardware as those who expect better utilization of the low end hardware.

Regardless of the computer specifications, the processor speed, or the GUI utilization one thing is certain: audiences are only getting more sophisticated. People who play multimedia expect higher sampling, more faithful color, higher compression ratios, more integration of video.

More than achieving a certain level of functionality with a certain subset of microprocessors, Broadcast 2000 was designed to present material to audiences. The computing infrastructure needed to meet those demands is going to match the problem domain.

> The plugins are nice. Are you encouraging people to write more
> for it? Is there any documention of the API? Have you heard
> of the LADSPA plugin API?

The Broadcast 2000 plugin environment is a simple, threaded, C++ class heirarchy, designed to speed up development. It doesn't expose you to the latest IPC techniques, uses threading a lot, and Linux hackers are usually not attracted to the idea of coding for pure functionality. So there isn't much justification in developing a SDK anytime soon.

The LADSPA was designed to be a very clean, tight programming interface, exposing the programmer to current trends in interprocess communication. If a significant number of LADSPA plugins emerged which added functionality above and beyond the current feature set, I would port the LADSPA plugins, but so far the LADSPA plugins have been basic studies in delay, scale, and mix algorithms.

> I'm curious about compiling bcast2000a ... does it need
> XFree86 4?
(note: the bcast website now has this info)

Compiling is very difficult. Unless you're intimately familiar with C++, you're better off getting a more powerful machine than re-enacting the software development process. There's very little to learn in compiling a productivity application, compared to compiling a kernel or a language.

You need an XFree86 4.0.1 development environment, Linux 2.2.17, version 2.2.16 of the firewire patches, and probably a bit of hand coding to merge the patches. The main problem users are having is version matching. Libraries once changed API's in major releases. Now they change API's in the point releases. The home-compilation outlook has continually gotten better but only enough to keep up with fragmentation over the years.

> What do you get if you purchase a broadcast bundle from

The main point of that is to support development of the software. I consider it donations to offset the $140,000 it cost to develop the software originally. Linuxmediaarts wants to deploy Broadcast 2000 in the professional market, which expects a corporate entity behind every tool it uses. Despite its penetration into academia, professional broadcasters would never have heard of Broadcast 2000 if it wasn't for corporate entities promoting it.

> Any interesting features coming up you'd like to tell us
> about?

The current objective is to pay for the previous version, continue to migrate the function prototypes as new kernels and C libraries come out, and work for the man. Since I ran out of cash to run the project, its fate depends more on whether the man wants to run video software on Linux boxes.

When you deviate from application specific contract programming, and basic computer science, you need industry funding to keep productivity applications flowing. Unlike most Linux packages, Broadcast 2000 emphasizes the outcome more than the basic computer science behind the outcome, and doesn't attract bedroom hackers the way CSound opcodes and common Lisp do.

Several years ago the audio suites were big, but now we're seeing industry converting to video suites. There's going to need to be more video support.

> ... and a scene setter ... Are you in Florida? (people
> like the geographical links)

I'm in Silicon Valley. I spent 3 years in Fl*rida before figuring out why everyone was over 50 and owned 5 companies. The economy in Fl*rida is bad enough that only the very top of the nation's best minds get to live there.

>Thanks Adam.

 home  music  news  opinion  software  tips  email