Subject: Re: [linux-audio-dev] ardour, LADSPA, a marriage
From: Tommi Ilmonen (tilmonen_AT_cc.hut.fi)
Date: Thu Nov 16 2000 - 20:20:31 EET
On Wed, 15 Nov 2000, Paul Barton-Davis wrote:
> >I think there should not be "an application", but plugins that can be
> >chained together. For example in Mustajuuri the mixer is not an
> >application by itself, but a plugin that can be used to host other
> >plugins. In future there may be other big plugins (like a decent hdr),
> >but the basic idea is to get away from the ProTools/whatever
> >"this is my application and there are its plugins" -kind of thinking. The
> >idea was sort of borrowed from SoniFlow (to credit the originators).
>
> The problem with this approach is that *something* has to be the
> host. There has to be a thread that is running in a synchronous loop
> with the audio interface, and that is responsible for executing
> plugins on time.
I wish to minimize the "something". It still exists, but it just those few
classes and objects that lauch the processing and sync the gui with dsp.
> In Ardour, that is represented by the ALSA::MultiChannelDevice object;
> not much of an abstraction, I agree, but thats a detail of the
> implementation, since there is nothing about this object that could
> not be easily abstracted.
>
> There is *nothing* to stop everything else in Ardour from being done
> as a plugin, except for the massive issue that LADSPA has no GUI
> support and we have neither resolved the legal issues regarding VST
> nor have we ported the libvstgui API to any Linux toolkit.
>
> If either a LADSPA GUI spec was here, or we could use libvstgui, I
> could implement ardour as a set of plugins. But they are not done,
> they will not be done for some time, and I would rather have a working
> program now. At the same time, I always code in a way that separates
> the GUI from the "engine", so there is not much to stop migration to a
> different architecture at a later date.
I completely agree with you. That is why I do not see this as coming
anytime soon. These days pretty much everybody writes stuff by having dsp
thread and ui thread so maybe we can unite them at some future time (=very
very wishful thinking).
> >better idea. Should look at other systems, but most seem rather awful -
> >not quite as bad as ProTools, but way too tied to the analog world.
>
> what is it that you don't like about these other programs, including
> ProTools ?
ProTools may have improved since the time I used it (sometime around 4.x).
The routing was most non-flexible. It was really difficult to insert
anything into audio strips below the strip input stage.
All strips were either mono or stereo. The work I had to go thru to make
a 6-channel mixdown was horrid. I wound up using "T. Ilmonen automation" -
wire ProTools output onto a wide analog mixer and use the grouping stuff
there to get multichannel panning right. Then mute/unmute regroup channels
at run time.
Other usages for multichanneling in more normal situations: Make an
n-channel group, apply eq to that and then split the group apart to later
process the streams separately.
And of course there was that huge amount of mouse-work to get anything
adjusted.
ProTools MIDI support (in/out/control) bordered non-existent.
Very basic problem was that you could not even open multiple plugin guis
at the same time. So if you have a reverb and an eq in the same strip they
could not be seen at the same time. In this case the problem is as simple
as not allowing the user to see what is going on in places that need to be
seen together.
So what is ProTools mixer section (I am not complaining too much about the
multitrack section): Derivative of an analog mixer with all the
problems but few of the benefits. There are a few improvements - for
example you can load setups from a file which is nice. I would expect
more innovation.
> >> Ardour really doesn't have to care about the EDL file format. Thats
> >> the easy part (especially when people like timevista supply a
> >> bison/flex parser for you :). The hard part is actually implementing
> >> what the EDL describes. I have, oh, 80% of that in place, but as yet,
> >
> >This is another reason to not make applications so very stand-alone. If
> >there is a strange file format there should be a plugin that is the source
> >of the format and the plugin should be able to automatically handle the
> >files - no need to parse information generated by other apps.
>
> I think that this maybe taking the "plugin" approach too far. We used
> to use "(shared) libraries" for this :) A plugin API that is designed
> for audio processing is not going to be usable for supporting plugins
> to read EDL files. I am perfectly happy with the approach that
Sorry, I must have misunderstood the role of EDL.
> >Now that I have talked about modularity I must confess people often hype
> >the idea. Modularity tends to be bad for usability. Holistic (or
> >monolithic) design gives the possibility to integrate all features to a
> >coherent packet. Or rather, modular systems *tend* to be difficult to use.
>
> Thats an understatement :) I will be quite happy if Ardour can end up
> doing what 90% of people do 90% of the time. We have some excellent
> tools for Linux that can allow very interesting experiments in modular
> software utilization for the remaining 10%.
Yep, lets hope it will work out well.
Tommi Ilmonen Researcher
>=> http://www.hut.fi/u/tilmonen/
Linux/IRIX audio: Mustajuuri
>=> http://www.tml.hut.fi/~tilmonen/mustajuuri/
3D audio/animation: DIVA
>=> http://www.tml.hut.fi/Research/DIVA/
This archive was generated by hypermail 2b28 : Thu Nov 16 2000 - 21:22:11 EET