2011/7/3 Paul Davis <p...@linuxaudiosystems.com>: > > 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