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.
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.
--
FA
Laboratorio di Acustica ed Elettroacustica
Parma, Italia
Lascia la spina, cogli la rosa.