6 Feb
2008
6 Feb
'08
9:28 a.m.
Fons Adriaensen wrote:
(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
On Mon, Feb 04, 2008 at 06:18:36PM +0200, Juuso
Alasuutari 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.
That being said, I still do favor D-Bus over OSC.
It's local only, no network support. 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?