The Linux Softsynth Roundup
If you've ever used Adobe Photoshop or The GIMP, you're already familiar with the concept of plugins. For normal users, a plugin architecture extends a program's capabilities without requiring an update or a recompile. For applications programmers, a plugin architecture allows them to concentrate on the basic design of their programs, letting the plugins provide more extended or advanced features.
Musicians working with Windows/Mac audio software can use plugins written to the Steinberg VST and Microsoft DirectX plugin APIs. Linux does not directly support either of those APIs, although we shall see an indirect method of support that does work under WINE. However, Linux audio developers have come up with their own native plugin architecture called the Linux Audio Developers Simple Plugin Architecture (LADSPA). The LADSPA API has become a standard, and support for it is now an expected aspect of almost any new Linux audio application. Some outstanding collections of LADSPA plugins are available that include not only the typically expected effects and DSP but also synthesis building blocks (oscillators, envelope generators, filters, etc.) and even some fully formed plugin synthesizers. There are some notable non-LADSPA plugins too.
Peter Hanappe's iiwusynth is a lightweight synthesizer that uses SoundFonts as fuel for its synthesis engine. Given a decent set of SoundFonts, iiwusynth's output is very good, and it has become popular as an embedded synth in many applications. It also can be used as a standalone synthesizer from the command line.
RX/Saturno is another lightweight plugin synthesizer that emulates the popular Yamaha DX7 FM synthesizer. Developer Juan Linietsky has indicated that RX/Saturno is still in the initial development stage, but it already is quite useful and can be employed as a plugin synth in any program supporting the ALSA sequencer.
Kjetil Matheussen's vstserver is interesting software that uses the capabilities of WINE to fool VST plugins into believing they're working in their native Windows environment. In most cases, performance is excellent, at least as good as under Windows. Kjetil also has written two clients for the server, one to hook VST plugins into Pd and one for LADSPA. The vstserver also supports some VSTi plugins, which are fully formed instruments such as synthesizers, samplers and MIDI sequencers wrapped into the VST plugin architecture.
Although LADSPA is an effective and popular standard, the “simple” aspect of its design prohibits certain kinds of processing and control. LADSPA plugins themselves do not permit direct parameter control via MIDI; though the plugins are quite usable in a MIDI sequencer such as MusE. Once again, the Linux audio development community has risen to the challenge with a new proposed standard called XAP. The API is in the design stages, but the team working on XAP includes the LADSPA designers and other talented Linux audio programmers.
The MIDI input hardware is typically a MIDI synthesizer keyboard, but any MIDI instrument can be used. Connection to a standard sound card requires a MIDI interface cable. OSS/Free and ALSA support MPU-401-compatible devices, so some standalone MIDI cards will work also. ALSA provides direct support for serial port and USB MIDI devices (I have not tested those connections myself) as well as the very useful virmidi virtual MIDI ports.
On the software side, the basic OSS/Free Linux sound system (the kernel sound system) is sufficient for working with the softsynths described here, but the recommended system includes the ALSA library and drivers, the JACK audio connection kit and a hardware MIDI input device. For best response, the kernel should be compiled for low latency, optionally with the preemptive kernel patch. The real-time clock (RTC) should be enabled also.
As of the 2.5 kernel development track, the OSS/Free sound system has been officially replaced by ALSA. Stable kernels from 2.6 onward will build only the ALSA system, which does have an excellent OSS/Free emulation layer for compatibility with non-ALSA-aware applications. Kernels earlier than 2.5 include the OSS/Free system, so users of those kernels must build and install ALSA themselves. ALSA has been designed for the kind of interconnectivity common to a modern sound system. ALSA provides API support for plugins, an advanced audio client/server architecture and a set of utilities to ease system configuration and management.
4Front Technology's proprietary OSS/Linux also works well with Linux softsynths, though obviously it can't take direct advantage of a network of ALSA sequencer clients.
JACK is a recursive acronym for the JACK Audio Connection Kit. It has been designed for low latency professional-grade performance as a software bus for the connection of out-of-process audio applications. JACK is somewhat similar in purpose to sound servers such as the aRts server for KDE or GNOME's esd, but JACK has been designed as a more robust solution incorporating pro-audio standards. Programs playing on the JACK bus can route their audio I/O freely between one another, permitting complex scenarios, such as routing the output of a MIDI-controlled softsynth into a hard-disk recorder while applying modulated plugin effects, all in real time with low-latency. Though a relative newcomer to the Linux audio world, JACK already has caught the attention of many developers and users, and we are rapidly approaching the point where its deployment and use will be a matter of course for Linux audio programmers and normal users alike.
Similis sum folio de quo ludunt venti.
|Designing Electronics with Linux||May 22, 2013|
|Dynamic DNS—an Object Lesson in Problem Solving||May 21, 2013|
|Using Salt Stack and Vagrant for Drupal Development||May 20, 2013|
|Making Linux and Android Get Along (It's Not as Hard as It Sounds)||May 16, 2013|
|Drupal Is a Framework: Why Everyone Needs to Understand This||May 15, 2013|
|Home, My Backup Data Center||May 13, 2013|
- RSS Feeds
- Dynamic DNS—an Object Lesson in Problem Solving
- Making Linux and Android Get Along (It's Not as Hard as It Sounds)
- Designing Electronics with Linux
- Using Salt Stack and Vagrant for Drupal Development
- New Products
- A Topic for Discussion - Open Source Feature-Richness?
- Drupal Is a Framework: Why Everyone Needs to Understand This
- Validate an E-Mail Address with PHP, the Right Way
- What's the tweeting protocol?
- Kernel Problem
9 hours 4 min ago
- BASH script to log IPs on public web server
13 hours 31 min ago
17 hours 6 min ago
- Reply to comment | Linux Journal
17 hours 39 min ago
- All the articles you talked
20 hours 2 min ago
- All the articles you talked
20 hours 6 min ago
- All the articles you talked
20 hours 7 min ago
1 day 32 min ago
- Keeping track of IP address
1 day 2 hours ago
- Roll your own dynamic dns
1 day 7 hours ago
Enter to Win an Adafruit Pi Cobbler Breakout Kit for Raspberry Pi
It's Raspberry Pi month at Linux Journal. Each week in May, Adafruit will be giving away a Pi-related prize to a lucky, randomly drawn LJ reader. Winners will be announced weekly.
Fill out the fields below to enter to win this week's prize-- a Pi Cobbler Breakout Kit for Raspberry Pi.
Congratulations to our winners so far:
- 5-8-13, Pi Starter Pack: Jack Davis
- 5-15-13, Pi Model B 512MB RAM: Patrick Dunn
- 5-21-13, Prototyping Pi Plate Kit: Philip Kirby
- Next winner announced on 5-27-13!
Free Webinar: Hadoop
How to Build an Optimal Hadoop Cluster to Store and Maintain Unlimited Amounts of Data Using Microservers
Realizing the promise of Apache® Hadoop® requires the effective deployment of compute, memory, storage and networking to achieve optimal results. With its flexibility and multitude of options, it is easy to over or under provision the server infrastructure, resulting in poor performance and high TCO. Join us for an in depth, technical discussion with industry experts from leading Hadoop and server companies who will provide insights into the key considerations for designing and deploying an optimal Hadoop cluster.
Some of key questions to be discussed are:
- What is the “typical” Hadoop cluster and what should be installed on the different machine types?
- Why should you consider the typical workload patterns when making your hardware decisions?
- Are all microservers created equal for Hadoop deployments?
- How do I plan for expansion if I require more compute, memory, storage or networking?