linuxaudio.org

On Sun, Jul 03, 2011 at 01:32:09PM -0400, Paul Davis wrote:

quoted text
> On Sun, Jul 3, 2011 at 1:09 PM, Emanuel Rumpf  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
_______________________________________________

Linux-audio-dev mailing list

Linux-audio-dev@lists.linuxaudio.org

http://lists.linuxaudio.org/listinfo/linux-audio-dev