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. _______________________________________________ Linux-audio-dev mailing list [email protected] http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
