Subject: RE: [linux-audio-dev] ardour, LADSPA, a marriage
From: Garth Brantley (garth_AT_fullduplex.com)
Date: Wed Nov 15 2000 - 18:58:53 EET
> -----Original Message-----
> From: Paul Barton-Davis [mailto:pbd_AT_Op.Net]
> Sent: Wednesday, November 15, 2000 10:39 AM
> To: linux-audio-dev_AT_ginette.musique.umontreal.ca
> Subject: Re: [linux-audio-dev] ardour, LADSPA, a marriage
>
>
> >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%.
It is a matter of achieving balance in the selection of modules.
Developing software on Linux is, afterall, a modular approach. Even
building a hardware device is a modular approach (you are merely assembling
IC and component modules).
-Garth
This archive was generated by hypermail 2b28 : Wed Nov 15 2000 - 19:38:42 EET