Subject: Re: [linux-audio-dev] ardour, LADSPA, a marriage
From: Paul Barton-Davis (pbd_AT_Op.Net)
Date: Wed Nov 15 2000 - 17:38:42 EET
>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.
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.
>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 ?
>> 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
timevista inc. have taken with their EDL format: they provide a
bison/flex parser that you can just glue into your code. Yes, it needs
tidying up a little for trivial use with Linux, but thats all. You
would just run:
gcc -o ...... -ltimevista
or something like that.
>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%.
--p
This archive was generated by hypermail 2b28 : Wed Nov 15 2000 - 18:25:29 EET