The Buzztard Project, Part 2: an Interview with Stefan Kost
This interview with lead developer Stefan Kost continues my report on the development of Buzztard. As the interview reveals, Stefan's work on Buzztard represents only one level of his deep involvement in Linux software development.
DP: Let's start with some background material. How long have you been using Linux, and what drew you into the Linux world?
SK: I became a Linux user when I was a student. At the university, one could choose between a PC lab running Windows (3.1/95 at that time) or a UNIX lab running Solaris. I was never that much of a Windows fan, so I worked mostly under Solaris. Somehow trying UNIX at home was a logical step, so I installed SuSE 6.0 on my home machine (our university had a subscription for SuSE Linux). That was roughly 1998.
DP: How did you get into computers? When did you start programming?
SK: Our family got our first computer around 1988 when I was 14. It was a Z1013 powered by a U880 CPU, which is an East German clone of a Z80. The fascination with programming for me is knowing that almost everything is doable—I just have to figure out how. After the reunion [of East and West Germany—DP], I bought an Amiga A2000 and expanded it over the years. I started to write several programs, mainly in C, for that platform. My sound editor, SoundFX, became quite popular.
DP: Your dedication to Buzztard implies that you have a deep interest in music. Do you have a background in music, formal or informal?
SK: I started to make music on the Amiga with software like ProTracker, StarTracker, Oktalyzer and Symphony. When I started working on SoundFX, I became interested in DSP algorithms and started reading lots of books to acquire the necessary background. I also started to learn how to play keyboards, although I never really had time for regular practicing. Nevertheless, studying musical theory a bit helped my compositions. Some of the music I wrote was used by Amiga Disk Magazin. At age 22, I started to become a DJ at Villa, Leipzig's oldest Gothic Club, and a bit later, I started a band called [ekso:r] with my DJ colleague. The music we made (and some of my own stuff) is available under the CC license at www.eksor.de.
DP: What attracted you to writing audio software?
SK: The fascination to tweak sound. The first version of SoundFX was very simple and basically a testbed for my curiosity. "What if I apply this algorithm to any signal? How will that sound?"
DP: Please, tell us more about the Buzztard project's design philosophy and goals.
SK: Most of the songs for [ekso:r] were written with a program called Buzz. It's a Windows freeware composer, but unfortunately, it's closed source. It took the concept of tracker applications a step further by using plugins for generators and effects. Unfortunately, a bad thing happened. Due to a disk failure, the author lost his latest changes, and he stopped the project in 2000. In autumn 2008, he started to continue again from an older backup. In 2002, I lost a song due to a crash in Buzz. I realized how important it is to use an open-source application for creative work—that's the only way to preserve creative work across decades. I registered the project on SourceForge and started making plans with a friend. We had chosen Buzztard as the name for two reasons: the Buzztard.org domain was available, and we liked the mix of Buzz and bastard (it's not a tracker, and it's not a classical sequencer). One important consideration was that we wanted to be able to load the original songs, so first, we wrote command-line test applications for loading the Windows plugins under Linux and loading the songs. Once we were positive about that, we started with the UI work. The main goal is first to support the similar functionality in Buzz. There are many ideas that go further, but that will depend a lot on how the project grows. For example, because we have selected the GStreamer multimedia framework for the engine, it would enable the inclusion of video as well as audio elements in a song.
DP: Some readers will want to know about the relationship between Buzztard and the original Jeskola Buzz. Is there any compatibility between the programs? Are there any utilities for converting original Buzz files and machines to Buzztard's formats?
SK: The Buzztard project is decomposed into several modules. Buzztard itself works on various platforms (I have an experimental version running on my Nokia N810). Loading Buzz's plugin DLL works only on x86 for technical reasons. We have a few plugins as open source, and those can be built on any platform. It's an ongoing effort to contact the authors and ask for the sources. The Buzztard importer for Buzz songs is also portable, but, of course, songs require the plugins to be available. The song loader is quite complete, and we also can load most plugins, but not all work as expected yet.
DP: How does Buzztard compare to Buzz at this point? Have you had any reactions from Buzz users?
SK: We got positive reactions in Buzz user forums. Many people like the nice UI. But, Buzztard still misses some features here and there. The project home page has a roadmap that details how we will address those. On the other hand, Buzztard already has nice some features that I missed in Buzz.
DP: It seems to me that Buzztard is in a usable state at this point. What do you consider the project's most important remaining development goal?
SK: One nice feature in Buzz is that you can work on a song while it plays. In Buzztard, you can edit patterns and the sequence, but it's not possible right now to add/remove generators and effects during performance. You need to press Stop, make the change and then press Play, which seriously hinders the creative process. The current development version has undergone some major changes needed for this feature, so hopefully, we will have that soon.
DP: What do you think about the state of Linux audio?
SK: There are a lot of cool bits and pieces. I sometimes feel like it's the remaining 20% that is constantly missing, but then again, there are many capable minds at work. I am quite optimistic.
DP: Do you have any plans for other Linux audio applications?
SK: Not at the moment. I also am involved in many other activities, and I know that I'm not very good at doing many things in parallel.
DP: You're involved with the GStreamer project. What kind of work are you doing for that project? Are you involved in any other coding projects you'd like to mention?
SK: When I started to work on Buzztard, I also worked on it at the university. I had the GNOME desktop running on a Sun. I was studying which software I could use to build Buzztard. It was clear that there is no single audio API available. GStreamer takes care of that problem. Then, I also needed a plugin interface, and GStreamer also offers that. Those things and many other reasons got me into GStreamer. Naturally, I quickly found many things missing. After all, GStreamer mostly was used for players at that time. In the spirit of open source, I contributed patches and quickly became a member of the project. Most of my contributions are related to audio creation tools, but as I am working for Nokia, many changes also target performance and other areas. I also work on other GNOME projects. A while ago I took over the development and maintenance of gtk-doc.
DP: Finally, what does Stefan Kost do with his life outside of Linux and computers?
SK: Actually, not very much. I try to balance my life between music, development and my family (which has just become larger—on February 8, 2009 my second son was born). I like ice skating and going to concerts.
Stefan Kost, Buzztard Project Team Leader
There we have him, folks. My thanks to Stefan for taking the time for this interview, and I must add that he also was most helpful as I learned how to build, install, configure and use Buzztard. I'm something of a perpetual beginner, but Stefan patiently walked me through the paces until I understood the program. Given his evident dedication to Buzztard and GStreamer, I'm confident both projects will continue to evolve nicely.
Coming up: a look at the audio hardware in use here at Studio Dave. Until then, breathe deeply and stay well-tempered.
Similis sum folio de quo ludunt venti.
Practical Task Scheduling Deployment
July 20, 2016 12:00 pm CDT
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.Register Now!
- SUSE LLC's SUSE Manager
- My +1 Sword of Productivity
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- Non-Linux FOSS: Caffeine!
- Managing Linux Using Puppet
- SuperTuxKart 0.9.2 Released
- Doing for User Space What We Did for Kernel Space
- Google's SwiftShader Released
- Parsing an RSS News Feed with a Bash Script
- Rogue Wave Software's Zend Server
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide