Re: [LAU] Jconv

On Fri, Mar 27, 2009 at 07:42:05PM +0100, Jörn Nettingsmeier wrote:

> Fons Adriaensen wrote:
>
> > I'm developing a mixer app that has a more ergonomic
> > layout for this sort of thing. It wil also do ambisonics
> > and provide filters, dynamics, equaliser and delays on
> > each channel.
>
> while you're designing it, could this stuff be separated so that it's
> easy to split it into an lv2 "Ambi channel strip" plugin and a lv2
> reverb section later? this way, it could be used in ardour without
> having to duplicate code...

The simple answer to this is no.

I've been analysing and exploring this for almost
two years now, and the conclusion of this is that
two things I originally wanted to do will not
happen. One is basing the design on LV2 somehow,
and the second is using jack for internal routing.

Regarding LV2, this would be possible in theory,
by defining a number of extensions. This would
mean:

- I have to define the extensions. Some of them
  are likely to be in conflict with existing ones,
  or to create ambiguities which are not resolved
  by the current specs.
- I have to write a host supporting the basic API,
  all existing extensions, and my own.
- The chance that other hosts will adopt the new
  extensions is small.
- I have to complicate things no end by handling
  basic and essential things as extensions.

Apart from that, the nature of the extensions I'd
need would mean that, apart from the extension
mechanism itself, *nothing* would remain of the
basic LV2 API. Things like its initialisation and
process methods would be replaced *completely*.
For a host author it would actually be easier
to add a new plugin API than to add the extensions.
There have been serious discussions with the LV2
devs some time ago, these have led to nothing.
The standard answer is: "this can be provided by
an extension" which has the same usability level
as "Jesus will take care of it", or "this would
be too complicated for a novice programmer who
wants to write a simple plugin", which amounts
to a voluntary limit on the scope of LV2.

Regarding Jack, it is not moving in the right
direction.

- Port locking has been removed. I'd actually
  need this to be expanded rather than removed.
- Port 'ties' are deprecated and will be removed.
  There is no simple and efficient alternative.
- The latency issue. About a month ago Paul Davis
  posted his new latency calculation scheme and
  invited comments. I did reply, and one of my
  comments was that this scheme, while correct,
  provided only half of the required functionality.
  No reply at all to this, nada, niente. Either
  the matter is forgotton for the time being, or
  something is being developed in some closed
  group and we will some day have some solution,
  which may be satisfactory or not, imposed de
  facto. I can't take that risk.
- Jack is getting too fat. We now have the scary
  situation that a non-audio connection can affect
  audio timing by creating a loop.

Regarding integrating some of the things I will
implement as plugins in Ardour, this would be
possible, but some of the essential functionality
will be lost. Some of the design, in particular
in the GUI and global management areas is radically
different, and Ardour has its history, both in
terms of existing code structure and acceptance
of its current personality by users. Apart from
that it has a much wider scope than just being
a mixer, and also that has its consequences.

Ciao,

-- 
FA
Io lo dico sempre: l'Italia è troppo stretta e lunga.
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user@email-addr-hidden
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-user