On Sat, Dec 19, 2009 at 09:15:22PM +0100, rosea grammostola wrote: > 1) The 'one app with plugins' group. People who are focusing on one big > app, extended by plugins (Ardour, Qtractor, LV2/DSSI). This group > doesn't have much interest in a session handler.
And quite probably the authors of these apps are not very motivated to make them compatible with session handlers. > 2) The people who likes to work with different, small Jack applications > (ams, aeolus, epichord etc.). These people are interested in a session > handler. But they think dbus is the wrong approach, it is to limited for > them, or it is not the right thing for the Linux platform in their opinion. 'Like to work' may not be the correct interpretation. See (4) > 3) Group 3 is the same as group 2, BUT they have chosen dbus as > solution. It's the LADI group. 4. And there's group 4, or maybe that group is just me. If there are others I'd like to know. For group 4: * Sessions are multi-host since there is no other way. In most cases all but one of the machines involved will be headless, and whatever is supposed to happen there is by definition remote controlled instead of being launched from a local desktop. * There are no usable 'single app with plugins' solutions since none of these comes close to what would be required, in particular w.r.t. the multi-host situation, and also because all of these apps silently assume a human user watching them and being able to take corrective action if necessary. Anything that could pop up an error dialog and refuse to proceed until someone reacts is completely useless in such systems. * Any interaction between components of such a system is supposed to use networked communication from the start. Dual-layer solutions based on some local IPC system plus some additional layer that would connect them via a network are just an unnecessary complication, and probably one that would not provide the right semantics, since the design would be based on the single host assumption in blissfull ignorance of what it takes to make things work together via a network. * Given the potential complexity of a networked system, loading a 'session' would in general not mean a complete teardown and buildup of all apps and their connections, but could just mean loading a different configuration in a single app, without even any others being aware of this. People using such systems are *very* motivated to create some form session handling, since controlling this sort of thing manually is a real PITA, in particular if you have to do it a hundred times a day, or if you have to provide an interface usable by non-experts. Which is why I have been working on this. And given the quite hostile reactions shown in recent threads, and the probably minute potential user base, the chances that the results will be made public are rather small. Ciao, -- FA _______________________________________________ Linux-audio-dev mailing list [email protected] http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
