Subject: [linux-audio-dev] a letter for review
From: Paul Barton-Davis (pbd_AT_Op.Net)
Date: Wed Apr 05 2000 - 21:28:00 EEST
I don't think there's much point any more in trying to hide the fact
that I am in touch with Steinberg, and discussing the possibilities
for Linux as a platform for their products. Below is the first draft
of a letter I am going to send them. Your editorial comments are
welcome.
--p
--------------------------------------------------------------------
Dear XXXX,
over the last week or so, there has been some active discussion
between people subscribed to the linux-audio-dev mailing list about
VST and Linux. Some has taken place on the list, some in private email
exchanges. This message attempts to summarize the results of that
discussion:
First of all, we are excited by and welcome Steinberg's interest in
Linux. The prospect of professional applications such as Cubase and
Nuendo running on our OS of choice is a thrilling one for us.
It is important to keep in mind that we have two interests at work for
us:
1) more and better audio software that runs on Linux
2) avoiding needless duplication of effort in writing and
using audio software on Linux
As far as #1 goes, we would welcome and encourage Steinberg to
undertake ports of their existing software to Linux, and there are
several of us who could function as design consultants if that was
necessary. However, I suspect that you have enough expertise inside
the company to accomplish this. We would be very interested to hear of
any concrete plans, doubts, uncertainties, questions you may have
about porting either Nuendo or, less likely it seems, Cubase, to Linux.
Generally, we view open source as an ideal method of addressing issue
#2. However, although an open source release of Nuendo would be
fabulous (!), I don't think that any of us are expecting this any time
soon. Instead, we want to focus on the development of a widely adopted
plugin API for Linux audio developers to use, which would also go some
way towards addressing #2.
At least a couple of us have already written prototypical VST hosts
and a couple of simple VST plugins. I personally have been vocal in
proposing that we adopt VST as a base standard for a plugin
architecture among the community of developers we have.
However, we have a number of concerns. First and foremost is the
current licensing arrangement with the VST API files. Although there
is no requirement in the Linux environment that all applications be
open source, the familiarity of open source software has made us all
very accustomed to freely exchanging source code. It is quite
problematic that although its possible for anyone to download the VST
API files and do whatever they want with them privately, they cannot
share the results. I'm not even talking about source code changes per
se here, but even just the organization of the files.
For example, it is very common to find open source software projects
using the GNU autoconf/automake tools, which allow automatic detection
of compiler characteristics, the presence or absence of certain header
files or libraries, various OS features and so forth. These allow
projects to be easily recompiled on widely differing platforms (e.g
the Win32 API, and a Cray). However, using these tools requires a
certain organization of the files. This can be easily done (it took me
10 minutes or less), but under the current license arrangement for the
VST API, I cannot release the results to anyone else. On one level,
this is a minor inconvenience - one of us could easily write a tool to
make the same changes that I did, and then have other people just
download the API and run the tool. But at a deeper level, its very
disturbing that the license does not allow even this basic level of
cooperation. Without this ability, there will be a definite level of
reluctance to use the API files at all.
Therefore, our first request is that Steinberg takes some action to
allow developers to share reconfigured versions of the API files. We
would find it ideal if you were to release the API under the GNU
Public License (GPL), and encourage you to consider this. There are
other existing open source licenses out there that may work better for
you. The LGPL and the MPL spring to mind as others that you could
consider. See http://www.opensource.org/licenses/ for more details.
Over the last month or two, there has been an ongoing
discussion/design round table about a new plugin API called
LADPSA. This work was started by Richard Furse as an attempt to
identify a simple plugin API that could be used by all the existing
Linux "plugin-friendly" audio applications. There has been a lot of
inputs from many different developers, including James McCartney who
write SuperCollider for the Mac. As of April 1st, LADSPA has now been
"released" at version 1.0 (its just a header file).
One of the consequences of this discussion is that we became very
aware of some of the strengths and weaknesses in the VST API. In
particular, it was pointed out that VST is not really suitable for use
a low level API for systems that use the concept of "unit generators"
or "opcodes". These are (potentially) simple pieces of code that
implement interesting DSP algorithms, and normally have little or no
UI associated with them. They are often used in real-time systems
where there are rigid bounds on the time they are allowed to take
during a single "process()" call, as well as during
instantiation. Such "unit generator plugins" require a more efficient
method of adjusting their internal state than VST's setParameter()
calls, and may also need to the host to support the notion of a signal
whose sample rate is somewhere between that of a constant and a real
audio signal (see the SuperCollider, Nord Modular and several other
"soft synths" for an example of this kind of system). LADSPA has been
written with a view towards this kind of "plugin" (though it still has
it critics, even for this purpose).
By contrast, VST has many benefits for plugins similar to those
already in existence - relatively heavyweight objects with GUI's of
varying levels of sophistication. Its also been demonstrated to be
quite adequate for the vast array of FX/EQ plugin systems that already
exist.
Because of Linux' excellent low latency performance, we don't want to
adopt a plugin API that is oriented only towards the kinds of plugins
that exist today in the Windows/MacOS world. I think that many people
in our community of developers would be happy to use VST right
now. But we would want/need to be able develop our own extensions to
VST, without losing 100% back compatibility with whatever the current
VST release is. The fact that VST is defined in C++ makes this easy
from a technical point of view, but the VST API license makes this
either hard or impossible to do.
So, our other request to Steinberg is to modify the license in a
second, more wide-ranging way, so that it was possible for us to do an
open source release of an extended version of the VST API (not called
VST) without trying to play games with the code. Yes, we could always
"re-engineer" the files and so forth to the point where it would hard
to say that we had copied them from you, but this would just be silly
and pointless. I think that we have a number of very smart people in
the linux audio development community who would be very interested in
seeing their ideas making it back into an extended API that was
VST-back compatible. Let me make it clear that we are not attempting
to take control of VST by suggesting this. We just want to be able to
use the API as a starting point for a plugin API that covers areas
that are not well handled by VST as it now stands. Our work would of
course by released under a license that allowed Steinberg to use it
without cost if you felt it was worthwhile.
As it stands, supporting VST plugins and writing VST hosts for Linux
is not of much value to us. The plugin API is not suitable for many of
the applications that are already plugin-friendly, and there would be
quite a bit of work to do in porting the vstGUI library. Worse still,
in the Linux world, we don't have a single GUI toolkit, and there are
lots of divided opinions on what would be the best toolkit to use for
such a port. It matters because its notoriously hard to get a plugin
that uses toolkit A to work in a program that uses toolkit B.
We/I are/am willing to work on the vstGUI library, but not if VST
cannot be extended to form an API suitable for existing Linux
software. So the offer we would like to make is that we (the linux
audio development community) could work on creating the infrastructure
for VST plugins to be ported fairly painlessly to Linux if in exchange
Steinberg is willing to allow us to use the VST API as a base for
developing more sophisticated plugin models. Steinberg would get a new
platform ready for use by plugin developers, for free, and we would
get (1) standard VST support and (2) a good chance at wide adoption
among non-commercial developers of a VST-compatible extended API.
sincerely,
Paul Barton-Davis
This archive was generated by hypermail 2b28 : Wed Apr 05 2000 - 23:22:53 EEST