Subject: Re: [linux-audio-dev] ardour, LADSPA, a marriage
From: Paul Barton-Davis (pbd_AT_Op.Net)
Date: Mon Nov 13 2000 - 16:31:47 EET
As ever, my thanks to Tom for a thoughtful and thought-provoking
post. Even if I sound dismissive below, as i tend to do (sorry!), i
really appreciate these issues being raised, especially by someone
with a real understanding of the design space.
>>i am pleased to mention that after a pleasantly short amount of
>>hacking, ardour CVS now has preliminary support for *real-time* LADSPA
>>plugins applied to EDL-based data streams. its far from where i want
>
>This added functionality raises a question. Do you plan to develop
>ardour into a monolithic daw application?
That has always been the goal, where "monolithic" is actually the
"monolithic+plugin" system, for reasons well described by David
Olofson in a follow up post. I don't believe that you can get
sufficiently low latency operation with chains of processes.
>My original understanding was that ardour was to be a hd replacement for
>a rack of adats, interfacing with a hardware mixer in a physical
>studio. Adding edl functionality was a logical development that allows
>it to become a rack of random access adats.
This is close to correct, but not quite.
The goal for version 1.0.0 of Ardour is to be a pure HDR system,
replacing a rack of ADATS/other HDR systems, interfacing with a mixer
in a studio.
However, the goal for version N is to be a system on a par with
ProTools, Paris or Nuendo. In order to accomplish this, it is
necessary to use an EDL architecture for editing, and this forces you
to use the same architecture for playback.
I decided that I would rather have version 1.0.0 already contain this
major design feature than have to introduce it later. It means it will
get more testing and use than if I introduce it after v1.0.0, and it
means that I can spend time after v1.0.0 working on truly useful
functionality rather than basic system design.
And then ... well, those who know me will know that I easily get
carried away. I discovered that there was really no way to make any
existing Linux soundfile editor playback non-interleaved multichannel
sources, and no way to efficiently edit interleaved multichannel files
of any real size. After i took a look at libgtkwaveform, i decided to
take a stab at an editor. And then plugins, and then ... :)))
>While the primary function of a mixer is mixing, it is also the home of
>the channel strip which contains inserts. Since ardour does no mixing,
>a mixer is still necessary and it will have inserts and the ability to
>handle stereo i/o fx. By adding inserts to ardour you have begun the
>process of fitting a mixer into ardour.
Yes, absolutely.
All plugins of the insert
>variety are mono, or linked stereo like a compressor. Stereo plugins
>like reverb and ping pong delay are not fed by inserts. They are fed by
>aux sends. You could feed them by mono inserts but you will still need
>to address stereo output.
Yes. With the current design, there is no other option than the mono
insert system. I wanted to try out the CMT plugin set, particular
freeverb. Reverb is critical to a lot of the sound I produce and my
Quadraverb is *so* noisy!
> Adding this kind of functionality to ardour
>creates momentum for monolithic development.
We have no choice, again for reasons that David summarized very well.
Note that the code that implements the plugins is NOT part of Ardour -
its dynamically linked external plugins from the CMT/LADSPA plugin set
generously provided by Richard Furse and others.
>...if you plan on developing a monolithic software daw. You could go
>modular, allowing ardour to stay as ardour. This approach would require
>the identification of the main components of a hardware studio,
>developing equivalent software modules, and developing a standard
>communication protocol between modules.
The moment someone defines such a protocol, and it can work with 5msec
end-to-end latencies, I promise you that Ardour will be converted to
use it. Until that time, there is no way of doing that you describe
with individual processes.
>because there is less communication overhead. However, new developments
>like 5.1 mixing are harder to implement if they must be integrated into
>a pre-existing monolithic application. Assuming that hardware
>technology development will continue to advance, communication overhead
>will be a non-issue (and for modest track counts it probably is
>already).
This is not true. OS overhead has increased as chips have gotten
faster, not decreased. I spent 4-1/2yrs working in a research group at
UWashington that was focused on figuring out what this happened and
how to reverse it (ask me more if you really want to know). Anyway,
its not track counts that are the problem, its the number of elements
in the processing chain. Each time we have to do a context switch, we
deterministically add time, and we run the risk of actually blowing up
due to unforeseen scheduling decisions on the part of the kernel.
>The modular approach will allow users to assemble virtual
>studios, with individual modules plugging into each other in a fully
>compatible mix-and-match way just like current analog technology.
I'm afraid that for the foreseeable future, the closest we can get to
this are plugins with their own GUIs.
>On
>the development side it may eliminate so much reinventing of the wheel,
>since someone developing a 5.1 mixer may start from scratch because he
>feels that would be easier than starting with an application that has
>recorder roots. He would probably be right but he would also loose all
>of the fine tuning in ardour regarding issues such as disk i/o.
Nope, they would do what DigiDesign, Steinberg, Mackie and everybody
else with 5.1 output has done: write a 5.1 mixer plugin. Theirs are
very nice, and I imagine that Ardour will have some nice ones in due
time. If someone let us the source for a VST one, we could have very,
very soon.
>It may be that the effort to fit a mixer into ardour would be more
>useful if it were applied to the creation of a communication protocol
>that allowed ardour to stay as it is.
I don't personally believe that a general purpose OS such as Linux can
support a protocol that would satisfy the requirements. If someone can
prove me wrong, more power to her.
--p
This archive was generated by hypermail 2b28 : Mon Nov 13 2000 - 17:21:23 EET