On Wed, Oct 10, 2012 at 2:04 PM, J. Liles
<malnourite@gmail.com> wrote:
[ ... ] but that's understandable considering that most Linux Audio programs are maintained by single developers (with lots of other projects) or small groups.
[ ... ]
My personal frustration with Linux Audio is mainly focused on the seemlingly iron-clad (but flawed) JACK API. We've needed the ability to rename clients and have ports with arbitrary event payloads (to allow MIDI, OSC, or whatever other streams to be managed via the JACK connection graph and frame clock) for years. And, even though many proposals have been made and patches submitted, it doesn't look like the JACK API is ever going to be improved--which doesn't speak well at all for the future of modular audio on Linux
see your quote above. here's the process:
* people identify an issue with the JACK API
* there is discussion of various approaches to the issue
* one or more people propose actual coded solutions
* there is more discussion
* potentially, one or more of the coded solutions is modified, followed by more discussion
* if no solution rises to the top, the issue remains unaltered
* if a solution rises to the top, AND if there is a clear consensus that its the right solution,
then it goes in. this final step is the only one where my role as "benign dictator" kicks in
since its typically me who decides whether the solution has emerged and whether there
is broad consensus.
lets look at the situation with MIDI sysex messages for example. the lack of support for arbitrary length messages is a genuine and real issue, though doesn't affect the overwhelmingly common uses of JACK MIDI. it has been discussed extensively. there have been 2 coded solutions proposed. despite this, i don't feel that there is really a consensus that either of them is really "right". as a result, the issue remains outstanding. people are free to challenge this decision based on disagreeing with my assessment of any of the steps outlined above. you could insist, for example, that there is a consensus. you could even insist that its silly to go for consensus when so few people would use or even care about the nature of the solution. i'm open to all of that, except that i want to see a meta-consensus in that latter case (i.e. a consensus that no consensus is OK for this particular issue).
there are many areas where the JACK API could use some work. the only one that i am aware of where there is reasonable consensus is the port metadata API, which has not been implemented purely because of the reasons outlined in your initial line above.
(such improvements are unnecessary for monolithic applications such as Ardour since they duplicate all this functionality internally) .
actually, no. Ardour has only recently started "duplicating" any of this functionality internally, and even then, its for very limited purposes. it uses JACK for more or less everything, and does not duplicate much of JACK's functionality at all. Ardour2 continues to use JACK for all audio routing, for example.
If an API is going to be fixed and rigid, it must also be extensible (like LV2).
that doesn't seem to have held back a bazillion other APIs, including at least 2 other "notable" (non-free) audio plugin APIs. neither VST nor CoreAudio are extensible, but this does not appear to have held back hundreds of plugin developers from creating plugins for those APIs. if we're looking for reasons why plugin developers do not develop (as a rule) for Linux, i think that the extensibility or non-extensibility of an API is probably not the place we'll find the answer(s).