2011/7/4 Jörn Nettingsmeier <[email protected]> > On 07/04/2011 03:23 AM, Paul Davis wrote: > >> 2011/7/3 Dave Phillips<[email protected]**>: >> >>> Jörn Nettingsmeier wrote: >>> >>> ... none of the audio stuff i routinely do everyday would be possible >>>> without jack. >>>> >>> >>> Amen to that. >>> >> >> I disagree with both of you. I think what you really mean is "none of >> this would be possible without some system for interconnecting >> processing elements together in flexible, creative,possibly >> unanticipated ways that also leaves the developers of those elements >> free to do things in their own way". >> >> that much i'd agree with. but this is not a description that requires >> that the solution be at the process level. >> > > well, like ladspa, jack has its time and place, and it has triggered an > amazing surge of activity. to me, it's the best infrastructure in the > market. > when it was conceived, there was no way to do what it does except at the > process level. and now that we know how to combine multiple gui toolkits in > a single process, it still looks very good. > > and as long as jack keeps scaling over multiple cpu cores, we have cycles > in abundance - so where's the harm in some inter-process communication > overhead? > > rather than lumping all audio into a single process, i'd say jack should > even strengthen the boundaries between processes, such that it doesn't die > as easily when a node in the graph goes bad, to make it even better suited > for live use than it already is. >
With JackSession quite some drawbacks of JACK will be countered. It is / was very user unfriendly to all the plumbing yourself again and again. Anyway, we're getting a bit offtopic here. You might want to start a new thread about the past and future of JACK and a plugin API (LV2) Regards, \r
_______________________________________________ Linux-audio-dev mailing list [email protected] http://lists.linuxaudio.org/listinfo/linux-audio-dev
