Re: [Jack-Devel] major change in jack1 MIDI handling

PrevNext  Index
DateSat, 12 Oct 2013 20:48:36 +0200
From Christian Schoenebeck <[hidden] at crudebyte dot com>
To[hidden] at lists dot jackaudio dot org
In-Reply-ToNedko Arnaudov Re: [Jack-Devel] major change in jack1 MIDI handling
Follow-UpPaul Davis Re: [Jack-Devel] major change in jack1 MIDI handling
Follow-UpJoakim Hernberg Re: [Jack-Devel] major change in jack1 MIDI handling
Follow-UpPaul Davis Re: [Jack-Devel] major change in jack1 MIDI handling
Follow-UpNedko Arnaudov [Jack-Devel] C++ and the code monkey business (Was: major change in jack1 MIDI handling)
Follow-UpBrendan Jones Re: [Jack-Devel] major change in jack1 MIDI handling
On Saturday 12 October 2013 18:41:11 Nedko Arnaudov wrote:
> I for sure would prefer a plain C version (with "proper" object oriented
> design, of course). With C++ silly attempts to mature/catch/improve, I
> doubt it will be any stable and prevailing "proper" C++ approach before
> 2020, maybe even later.

You will never like it, even not after 2030. The C++ language is only 
extended, but existing parts of the language are not revised, due to backward 
compatibility reasons. The C++ committee is very strict on that policy. What 
you are asking for is a new language.

> What really matters is the code and fixes developers contribute. There
> is no ubiquitous single jack leadership, like it or not. We curently
> have two persons acting as jack leaders. They don't really fight each
> other but they have some really strong differences. And more
> importantly, we have two codebases that are not going to vanish anytime
> soon. 

I don't mind about how many "leaders" there are, nor do I care about preferred 
code style, naming conventions, internal topology decisions or the programming 
language being used. Those things are too much connected with personal tastes, 
which almost never match. Only people with a *lot* of time or money can enjoy 
that luxury. ;-)

I am just directly comparing use case benefits and future potential of 
implementation JACK1 vs. implementation JACK2 and see no single (rational) 
advantage in JACK1 in that direct comparison.

And with distros it's a nightmare. Some distros use JACK1, some JACK2, some 
ship both, but then they are not optimally packaged, which regularly causes a 
newly compiled app to crash, because it compiled and linked against JACKx, 
while accessing server JACKy at runtime, which sometimes is hard to resolve. 
And if you want to switch from one JACK to the other, you might need to 
recompile half of your system.

Short: this open source diversity is in this particular case of JACK simply 
annoying and unnecessary.

> Other contributors may differ, but to me neither jack1 nor jack2
> are inspiring. To me fighting between open source projects and
> developers makes absolutely no sense. We are supposed to be
> collaborating instead. Maybe the consensus is that there are very few
> [potential] jack contributors and this makes diversity look like fight
> for something limited.

The notion of - let's say emotional involvement - easily comes when you just 
lurk on IRC and wait for a user question about JACKx, and the first reply will 
actually be a question: "Why are you using JACKx, not JACKy?".

I am stunned about how strong the positions are about those two, considering 
that JACK is "just" a sound server, not a desktop environment. I would rather 
like to see that energy being used for JACK to finally supersede PulseAudio as 
default server on major systems.

CU
Christian
PrevNext  Index

1381603395.8817_0.ltw:2, <201310122048.36579.schoenebeck at crudebyte dot com>