[LAD] Summercode 2008: LASH, pt. 3

[Juuso Alasuutari]

Fons Adriaensen wrote:
> On Mon, Feb 04, 2008 at 06:18:36PM +0200, Juuso Alasuutari wrote:
> 
>> That being said, I still do favor D-Bus over OSC.
> 
> It's local only, no network support.

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.

>>> For anything like lash to be useful here it would need to support
>>> this layering.
>> Can you give specific examples of what you mean by this layering concept?
> 
> (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.

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