5 Jul
2011
5 Jul
'11
12:40 p.m.
2011/7/4 Jörn Nettingsmeier <nettings(a)folkwang-hochschule.de>
On 07/04/2011 03:23 AM, Paul Davis wrote:
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
2011/7/3 Dave
Phillips<dlphillips(a)woh.rr.com**>**>:
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.
Jörn Nettingsmeier wrote:
... none of the audio stuff i routinely do everyday would be possible
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.
without jack.
Amen to that.