OK. I am not flicking switches to go from any to any other. I am sending MIDI events, which are triggering synths, and sending data along JACK paths which do not and are not changed after they are built, as long as the box runs. That's why it's called "Concurrent Patch Management" ( http://lsn.ponderworthy.com/doku.php/concurrent_patch_management ).Nope, I don't want to switch engines. Everything runs at once, and runs very well by the way. I just want to take more advantage of what I have, by running some things asynchronously, exactly the way some are already doing using multiple motherboards.
although it isn't proven yet .. i think that your problem may come from the fact that you want to have 19 different engines, and you keep flicking switches to go from one to the other.
the "engines" i'm referring to are your many multiple clients (19 or so).
No, I know very well that nothing in a single JACK system runs asynchronously. The point is that if a single JACK system cannot be flexible enough to use most of the computing power I have, because of the limitations of any synchronous design, multiple JACK systems will be employed within the one box, just as others already employ multiple JACK systems on multiple motherboards to serve the same purpose. I am hoping to avoid having to run each JACK system in its own Docker container, and at least in theory, it should be possible to do this using netjack1, netjack2, or jacktrip, but it appears that either localhost may not have been tested very much as a network for these, or there may be another limitation somewhere of which I'm not aware which prevents that from working.i think you're still confused by terminology here, in a way that doesn't advance your situation. Nothing in a JACK system runs "asynchronously". Everything is "synchronous", which means that within a given process cycle, all clients will be processing audio samples taken from, or to be written to, the same locations in the hardware buffer of the audio interface in use. They work on the same "time slice". Changing this would break the fundamental assumptions and design of JACK (all versions).
No, I am not. I am talking about expanding the paradigm at large, to use available resources, however it can be done.what you are talking about is parallel vs. serialized execution of clients (which some might term "sequential execution"). parallel execution means that clients can be distributed across cores or cpus or whatever; serialized execution means that only 1 client can execute at a time, so unless that client has its own internal processor-level parallelism (e.g. ardour), it will make no difference how many cores/cpus/mobos you have - only 1 of them will be used at a time.
In point of fact it works very nicely right now, as far as it can. I have to admit that I don't care how JACK was intended to be used; I care merely what it can do. Certainly the tools which the Wright brothers used in 1903 were never designed to build airplanes :-)your workflow has some parallelizable elements and some elements that must be run serially/sequentially. it is an odd design, significantly outside the intended scope of what JACK was intended to be used for. some people think it can be made to work for a flow like this.