2011/7/4 Jörn Nettingsmeier <nettings@folkwang-hochschule.de>
On 07/04/2011 03:23 AM, Paul Davis wrote:
2011/7/3 Dave Phillips<dlphillips@woh.rr.com>:
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