On Wed, Oct 10, 2012 at 4:09 PM, Fons Adriaensen 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
