Re: [Jack-Devel] The Situation(s) With JACK

PrevNext  Index
DateThu, 08 Dec 2011 10:16:02 -0800
From Devin Anderson <[hidden] at charityfinders dot com>
ToPaul Davis <[hidden] at linuxaudiosystems dot com>
CcJACK <[hidden] at lists dot jackaudio dot org>
In-Reply-ToPaul Davis [Jack-Devel] The Situation(s) With JACK
Follow-UpStéphane Letz Re: [Jack-Devel] The Situation(s) With JACK
On Thu, Dec 8, 2011 at 5:04 AM, Paul Davis <[hidden]> wrote:

> 1. there are at least 3 different implementations of JACK. This is not
> a problem in and of itself, but in the real world, it contributes the
> remaining problems in real ways.

From a JACK driver perspective, it certainly makes things difficult.
For a few months now, I've been tempted to port the 'alsarawmidi'
slave driver to JACK 1, and each time I start, I think about
maintaining two sets of code that do the same thing in two different
languages with two different driver APIs, become frustrated, and find
something better to do with my time.

> 7. any new extensions to the JACK API (such as an upcoming metadata
> proposal from David Robillard and myself) require duplicated effort
> across different implementations, which is silly and not very
> productive.

This applies to the driver problem too.

> 13. The only people to do work on JACK development over the last
> couple of years confine themselves to specific versions of JACK, and
> despite nominally friendly communication, do not really collaborate
> with the others. (Note that I am including myself in this).

This too.

> I do have a proposal for how this is going to stop, but before I put
> it forward, I would like to first see if there are any other ideas
> floating around on the mailing list that have not come up when I've
> discussed this situation on IRC. Once any discussion about this email
> settles down, I'll outline my proposal (whatever it ends up being at
> that point).

Back in July, you said this:

> what *should* have happened was a plugin API that as many developers
> as now use JACK would have agreed to adopt.
>
> what could have happened was something like JACK.

LV2 looks better to me all the time.  I had reservations about LV2
because of the lack of transport sync, but the new 'time' extension:

    http://lv2plug.in/ns/ext/time/

... seems like an elegant solution to the transport problem.

I'd personally like to see momentum shift to LV2.

I'll go out on a rather shaky looking limb and say that I'd like to
see JACK become a library that is used to route audio and MIDI data
'inside' an application (e.g. between plugins), and continues to
provide bindings to hardware.

-- 
Devin Anderson
devin (at) charityfinders (dot) com

synthclone - http://synthclone.googlecode.com/
PrevNext  Index

1323368180.29267_0.ltw:2,a <CAG7zqTqyJCvJHZvS7kHf92Z-k-uJWgVFvmLNiC5zwspcox9TbQ at mail dot gmail dot com>