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
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Received on Wed Feb 6 16:15:03 2008
This archive was generated by hypermail 2.1.8 : Wed Feb 06 2008 - 16:15:03 EET