On Wed, Oct 10, 2012 at 4:09 PM, Fons Adriaensen
<fons@linuxaudio.org> wrote:
I agree with J. Liles that we should have the courage to review
Jack. It has done a very good job, but (at least in my world) it
is showing its limits, and I'm not at al convinced that these can
be removed by 'incremental' improvements. Maybe we need something
new and incompatible, with two systems existing during a transition
period which could take several years. In particular:
I'm also open to something new/radical. But frankly I'd settle for incremental improvements too. One can always deprecate a feature later if it turns into a problem. But it's important to actually *try* these things in the ecosystem so that people can see the difference between all these theoretical problems they're so ready to imagine and what actually comes up in practice. Right now JACK is the thing that connects all of this stuff together, and IMHO, progress will blossom as the bandwidth and expressive quality of this connection is increased.
* It sould become a system level service, i.e. 'promiscuous'. I've
been running modified versions like that for some time. It's a
pain currently. Things will maybe improve once systemd becomes
universal.
Agreed, but with autostart and jackdbus, I don't think many users are having trouble with this aspect anymore.
* It should have 'persistent' ports or the equivalent. That is, you
can start an app, and tell Jack to remember it and its ports even
after the app is terminated. The point here is that others can
then connect to it even if it doesn't (yet) run. This would simplify
things like session management quite a lot. But it also requires
cooperation from the apps - one like Ardour that creates and removes
ports with arbitrary names at any time doesn't fit well into such a
scheme. The solution is to use Jack ports more like audio hardware
uses its interfaces: ports are a fixed set (as would be e.g. an ADAT
or MADI interface on a HW mixer), but are assignable to any function
*within the app*. Any notion of logical function can still be carried
as metadata of the port.
Fixed port names has its advantages and disadvantages. For one, it imposes another level of assignment/routing on the user (within the application). When you look at something like a DAW, I don't think it makes much sense to mangle all the ports into a fixed array of 32 channels or whatever. I certainly don't see how having JACK attempt to remember the connections would make session management easier.
* All current hardware is SMP. If an audio app has a complex internal
processing graph it will implement its own multithreaded scheduling
system for audio processing units (as Ardour 3 does). But it's silly
to repeat this in every app, and even more silly to schedule apps
'per process', i.e. run them only if *all* of the internal graph can
run. This level of logic should move into Jack, or whatever replaces
it.
Agreed. This is why I'm still confused why everyone seems to shy away from supporting multiple client per process programs (like Non-Mixer).
The plugin situation is deplorable. Let's face it, 90% of the available
ones just don't work, or work for some value of 'work' but are still crap.
LV2 has not delivered what was hoped for, IMHO as a result of focussing
on the wrong things. Given that things are what they are, any plugin
standard on Linux should have a documented and *stable* way to support
*any* X11 based GUI, including having a GUI embedded into an app, *and*
do that in a way that still works efficiently even if you have 100 plugins
in an single app and 500 in your system. Focussing on the right things also
means supporting developers who go for quality and are prepared for the
effort instead of trying to make things as easy a possible for beginners.
One of the reasons I'm not releasing anything as an LV2 plugin is that
LV2 doesn't impose any quality standards, and doesn't care about its
reputation. It's just bad company.
I think imposing quality standards is beyond the scope of a plugin API. Many plugins used in non-classical mixes are intended to reduce fidelity, not preserve it. I agree on the GUI, which is why I prefer the way DSSI handles this (GUI is a separate process, can use whatever TK it wants). Unfortunately, there are very few of us with the skill set required to make non-crap plugins.
Finally, and on a very personal level, you may have noticed that my
output has decreased. But it hasn't. I've written more Linux audio SW
during the last years than at any time before. I'm just less inclined
to publish it. And I have been asking myself why that is so. One factor
may be that much of it is rather specialised. But that is in itself no
reason to keep it private, so that doesn't explain things. What has
certainly played a role is that fact that I'm tired of the mostly
useless discussions that arise whenever you propose something that
challenges the status quo, and the need to reach a 'consensus' before
anything happens. Which is more often that not just used to kill some
idea rather than towards any productive end.
I've dealt with the same situation and feelings. I sat on the NSM prototype long enough to see one or two other session managers come on the scene in the meantime. I say release what you've done. You never know when you're going to get hit by a bus. Someone will find a use for it and be grateful.