<br><br><div class="gmail_quote">On Wed, Oct 10, 2012 at 8:33 PM, J. Liles <span dir="ltr"><<a href="mailto:malnourite@gmail.com" target="_blank">malnourite@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br><div class="gmail_quote"><div>Agreed, but with autostart and jackdbus, I don't think many users are having trouble with this aspect anymore.<br></div></div></blockquote><div><br>actually, on IRC, jackdbus's d-bus elements seem to be responsible for about 75% of all the user issues with JACK at this point (partly reflecting jack2+dbus adoption by so many distro's) <br>
<br>>Agreed. This is why I'm still confused why everyone seems to shy away from supporting multiple client per process >programs (like Non-Mixer). <br></div><div><br>multiple clients per process doesn't get rid of all the logic needed for SMP operation.<br>
<br>i'm working with a company at present that uses a design for their processing model that works the way you and others have suggested multi-client-per-process. they're a very, very well known audio software company and i think it would be fair to say that in our discussions of their model (discrete sets of processing elements grouped together for parallel execution, with each group sequentially following others, modelling a tracks->busses style of flow) that they came to see the benefits of a dataflow model. i don't see how you can fit a dataflow model into a multiclient system without things becoming incredibly complex.<br>
<br>i should note that AFAIK, jack1 at least will support multi-client-per-process, and if it doesn't, even if i'm not a fan of the design, i would consider a bug. <br></div></div>