On Wed, Oct 10, 2012 at 4:09 PM, Fons Adriaensen <f...@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.
_______________________________________________ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
