linuxaudio.org

2011/7/3 Paul Davis :

quoted text
>

> 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.

>

> --p

>

I see, that treading many different apps as one large entity (with

state management etc.)

is a difficult task. (That's why other systems decided for plugins, I think.)

Unix (as operating system) doesn't  particular help there. (Neither do others.)

New technologies are coming (dbus, cloud-apps, etc.)

but it's not clear to me, which is the best approach for such demands.

I'm not dispraising JACK.

It has been a very important innovation,

that has pushed audio application development for linux tremendously,

by creating a reliable base, with a not too difficult api.

Since you are one of the main actors there,

I really have to thank you for making this progression possible !
--

E.R.

_______________________________________________

Linux-audio-dev mailing list

Linux-audio-dev@lists.linuxaudio.org

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