Julien Claassen &lt;julien(a)c-lab.de&gt; writes: Given that there will be switch to D-Bus, such application will be very simple and quickly and easily developed using python. This was made already for jackdbus (jack_control app) and if nobody creates it before me, I'll create it for purposes of testing of dbus-ified lash during development and to be used for as simple as possible control app. And for atomic tests of the API too. -- Nedko Arnaudov <GnuPG KeyID: DE1716B0>

Bob Ham wrote: Your point of view is one of the reasons why this step is the last before all the rest. We will have more time to discuss the implementation details. :) Juuso

Fons Adriaensen &lt;fons(a)kokkinizita.net&gt; writes: The advantage is D-Bus autolaunching of the "server" and better integration with "desktop". This will be hard without proper integration with a desktop (window manager) session handler. Something very similar can be achieved using the "import subsessions" feature that I proposed earlier. I.e. have system session [auto]loaded and then import (without replace) of user session[s]. -- Nedko Arnaudov <GnuPG KeyID: DE1716B0>

On Mon, 2008-02-04 at 18:18 +0200, Juuso Alasuutari wrote: Why is freeing LASH from being a libjack client a goal? Bob -- Bob Ham &lt;rah(a)bash.sh&gt;

On Tue, 2008-02-05 at 09:32 +0100, Arnold Krille wrote: This was addressed elsewhere. The issue is the dynamicity of JACK. Rewriting LASH to use D-Bus because you don't want to fix JACK is lunacy. Bob -- Bob Ham &lt;rah(a)bash.sh&gt;

Marc-Olivier Barre wrote: ++ Juuso

Bob Ham wrote: I apologise for the sloppy language I used. I should've specified that with 'libjack' I'm referring to what libjack is at the present moment. In my opinion, LASH shouldn't communicate with JACK using the "normal" client lib. It goes against the concept (LASH is special; it's not your generic audio application), and it has its limitations. Some of the issues with the current libjack API are lack of engine and driver parameter controls, lack of control for stopping, starting, and auto-launching JACK, and the practical requirement that a port connection frontend be RT capable. (I've understood that the last one doesn't apply to libjackmp, though.) Most of these would be solved by a control interface to JACK, which is something that LASH should use. It could be a D-Bus interface that's built into JACK or, preferably, the control interface could be a separate library/API provided by JACK. This API could then be used to implement a D-Bus interface, an OSC interface, and LASH could use it directly. I'm starting to get a feeling that what I just said isn't all that new. Of course it's not my idea -- it's been talked about on #lad many times already -- but doesn't it resemble something that you suggested at some point earlier on, Bob? (What goes around, comes around.) Juuso

On Mon, Feb 04, 2008 at 06:18:36PM +0200, Juuso Alasuutari wrote: It's local only, no network support. (This is really the same issue that is driving my position in the autoconnect discussion that's going on in another thread.) Any setup in which some of the apps are not considered to be under control of the 'end user', but part of the 'infrastucture of the studio'. Examples are bi-amped systems with software crossovers, room correction, surround decoders matched to and calibrated for a particular installation, etc. It's the same when you work in a physical studio: you can use any instruments you want, make any music you want, use all the effects equipment, but you're not allowed to modify the studio itself. One way I'm investigating to more or less enforce this in an installation I'm designing is to have a second JACK instance that is not driven by a sound card but by a client of the 'master JACK' of which it becomes a subgraph. Then hide the 'master JACK' and all its clients. To the user it looks as if he's working with a normal installation, and talking to the sound card, while his 'system:' ports are in fact just another app. All it takes is a JACK backend that presents itself as a client to another JACK instance. Or a shared lib that allows any app to become a JACK backend. Or a version of JACK that has not one but several processing graphs and configurable links between them. That's one way to do it, another one is to use a 'flat' system (only one JACK) and rely on a session management system that supports hierarchical control. -- FA Laboratorio di Acustica ed Elettroacustica Parma, Italia Lascia la spina, cogli la rosa.

On Tue, 2008-02-05 at 15:34 +0100, Stéphane Letz wrote: AKA "netjack" :) it really almost exactly the same, except with two sockets as the interface between the JACK instances, rather than shared memory and IPC mechanisms. --p

Fons Adriaensen wrote: Sure, and while we're talking about the LASH<->client protocol I still don't see this being a problem. Any session that includes clients which reside on multiple hosts will still require a local lashd running on each host (even Bob agrees with this, which I didn't realize until before we talked about it on #lad). The protocol that lashd uses to communicate with its clients should IMHO be local. In practice, the clients would still simply link against liblash and use its API regardless of what liblash does internally. The internal protocol could be anything, as long as it's not a Swiss army knife that tries to do everything imaginable by itself. When looking at how a multi-host session would work in practice, it's obvious that what happens between the LASH daemons is key. This communication has, in my opinion, more in common with the current server interface than the client interface. Consider this (monospace font required): host host host B A C | | | | LASH control app | | | | -------------- --------------- -------------- |server iface|<=========|server iface |========>|server iface| -------------- --------------- -------------- |*LASH slave*| |*LASH master*| |*LASH slave*| -------------- --------------- -------------- |client iface| |client iface | |client iface| -------------- --------------- -------------- | | | client 3 client 1 client 5 client 4 client 2 client 6 Here the "master" host's LASH is controlled by a user interface application, and the "slave" hosts' LASHes are controlled by the master LASH, and both use the same protocol. The control interface is built so that it can tune in to both local and remote control messages. It may well be based on OSC. The client interface protocol has no network connectivity requirement. The type of commands that a LASH server might receive from an UI -- load project, save project, etc. -- are identical to those that it might receive if it were a slave listening to a network socket. (I wonder, for the second time today already, if this isn't what Bob had imagined as well. There have been some misunderstandings at least on my part during the discussion.) One more thing about the LASH client and server interfaces. Dave Robillard has expressed his opinion that the current situation where a liblash client can register as either client or controller is tricky. Patchage can't register as a LASH client and store some session-related settings because it also needs to register as a LASH controller. This calls for a fix, one solution being to completely separate/abstract away the LASH server interface from the current API. Very interesting thoughts. I'm afraid, though, that my circuit's too loaded with LASH protocol stuff right now for me to figure out how to fit your ideas into the domain of session management. :) Juuso