3 Jul
2011
3 Jul
'11
8:27 p.m.
2011/7/3 Paul Davis <paul(a)linuxaudiosystems.com>om>:
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.