>Before I go off ranting about the current state of audio guis, are you >saying that clients with different gui toolkits can't connect to the >same jack server? That seems kinda messed up to me... I feel like I'm >misunderstanding.
its not possible to have two instances of an X Window event loop in the same address space if they are both connected to the same X server (its tricky even if they are not). it simply won't work correctly, mostly because there is no way to make sure that events destined for one event loop go to that one rather than the other. since a GUI toolkit generally comes with its own main event loop, which handles both X events and other things too, it follows that you can't have code that uses both GTK+ and Qt (or XForms or fltk or ...) in the same address space. JACK solves this by allowing clients to be "out of process". This means that each client is running as a normal program with its own address space. This has a real cost to it, signficantly higher than the cost of allowing clients to exist within the server's address space. The cost is that we have to make IPC calls rather than regular function calls. Its not high (on the order of 50usecs on a PII-450, but varying due to many different conditions), but its much higher than a function call. Because of the toolkit issue, there's nothing we can really do about this. Some people have hacked up co-existing GTK+ and Qt event loops. They are, however, deep and ugly hacks, and nothing any of us would want to base a system wide architecture on. Current versions of GTK+ have a re-factored event loop that in theory might allow for co-existence. This isn't of much help, however, until all the other toolkits do the same thing. So, to summarize: clients using any toolkit they want can connect to the same JACK server as long as they are out-of-process clients. in-process clients must be using the same toolkit as the server. right now, that means no toolkit since jackd doesn't use one. --p
