[LAD] Feature requests: add JackSession support

Fons Adriaensen fons at linuxaudio.org
Mon Jul 4 14:18:19 UTC 2011


On Sun, Jul 03, 2011 at 01:32:09PM -0400, Paul Davis wrote:
> On Sun, Jul 3, 2011 at 1:09 PM, Emanuel Rumpf <xbran at web.de> wrote:
> > SaveAndQuit (without Quit only) is not so bad, as it appears
> > initially. Actually I seem to like the idea of this simplification.
> > Although one has to get used to it.
> >
> > What I'm really missing is SaveAndClose (without application Quit !).
> > Restarting all applications for changing a session doesn't appear
> > practical.
> 
> i feel that if you spend too long reasoning about this, you will
> conclude, as I have, that JACK was actually a mistake (at least in
> terms of the basic framework in which to glue together different
> things processing data streams). the absence of a plugin API that was
> likely to be adopted by all/most developers back in 2000 is what gave
> rise to this situation. there's a limit to how far you can push the
> usability of a "DAW" built out of N independent processes, each one
> running code developed by different developers with no awareness of
> the others. the limit is, thankfully, not too primitive, but its also
> not far enough out to be able to pretend that JACK + N>1 clients is
> actually functionally equivalent to a single host + plugins, at least
> not in terms of state management.

I don't think it was a mistake to provide flexible audio connectivity
between processes. Even if the ideal situation is to integrate things
to a level that typical users expect, 1) there are exceptions to this,
and 2) there is much more room  for integration between processes
than has been exploited up to now. 

As an example of (1), take the monitoring system here at the LABEL.
It can switch between

- 8 discrete channels,
- various AMB modes,
- stereo via two discrete speakers,
- stereo via virtual AMB speakers,
- 5.1
- ...

and for all of these the source signals can come from

- the local (linux) machine
- the MAC 
- the hardware mixer.

Future versions may also include room correction processing.

I wouldn't want this setup to be part of a session in a single integrated
production app, or even part of Jack Session It has nothing to do with
any project and should not be copied if a project is moved to another
environment. It's just part of the studio infrastructure, at least as far
as a typical user is concerned.

If there is one fundamental change I'd make to any Jack-like system if I
would design it now, it would be to make ports persistent -  they exist
even if the app they are associated with does not run. Similar to the 
fact that the analog (to a patchbay) and digital (to an ADAT/MADI matrix)
connections of the hardware mixer here exists even if it is switched off.

This in turn encourages fixed or at least semi-permanent port wiring, 
with  most of the flexibility being provided by the applications, which
would be able to use any port for any function, as is the case for the
mixer app that I'm developing.

Having a semi-permanent set of endpoints and connections greatly 
facilitates setting up and managing sessions. And it does not make some
desirable forms of integration impossible. For example there is nothing
that would stop e.g. my mixer app to read an Ardour session file and set
up itself according to the track list, including setting the channel
labels on the mixer.

(BTW it would be great if Ardour would provide raw track ouputs)

Ciao,

-- 
FA




 




More information about the Linux-audio-dev mailing list