On 07/03/2011 07:32 PM, Paul Davis wrote:
> 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.
true if you are arguing from the "streamlined workflow" pov only.
but the unix way is "make simple things easy" (= use one daw and
everything else is a plugin) _and_ "make hard things possible". jack
doesn't hurt the former and excels at the latter. none of the audio
stuff i routinely do everyday would be possible without jack.
it's great to be able to combine stuff in ways the developers did not
(need to) anticipate. that usually means combining separate processes.
jack is really unixy, and it certainly deserves the highest praise i
could think of: it's totally |y.
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/listinfo/linux-audio-dev
Received on Mon Jul 4 04:15:02 2011
This archive was generated by hypermail 2.1.8 : Mon Jul 04 2011 - 04:15:02 EEST