Roland Cahen

Is there any way (else than poly~) to route different processes, threads or patchers of max/msp/jitter to different processors in order to optimize process ?

For example, can openGl or jitter be routed to a different processor from audio ?

Which are the "Many CPU based Jitter objects exploit multi-processor and multi-core systems to take advantage of all the resources available to today’s systems" in the Multiprocessor support of Jitter Features ?

Is there any way (else than poly~) to route different processes, threads or patchers of max/msp/jitter to different processors in order to optimize process ?
For example, can openGl or jitter be routed to a different processor from audio ?
Which are the "Many CPU based Jitter objects exploit multi-processor and multi-core systems to take advantage of all the resources available to today’s systems" in the Multiprocessor support of Jitter Features ?

multiprocessors-distibuting-processes-on-different-threads-and-processors

1 - there are ways you CAN control the threading of MaxMSP (defer / scheduler in audio interrupt / scheduler in overdrive / poly~) etc. These are documented, and searching this forum should turn up more than a few topics about this.

2 - Most of the time the allocation of threads to CPUs or CPU cores is not handled by end user software, but much deeper in the OS/Hardware system. Before Mac OS 10.4 or 10.5 (I forget which) there wasn't even a way to suggest how a thread should relate to CPU cores on the Mac OS - after that there was a processor affinity option, but even that does not guarantee that a certain thread will always run on a certain CPU core. In other words the model you're dealing with here is assigning things to threads, and allowing the system to divide those between CPUs as appropriate.

3 - If the scheduler is not in audio interrupt than the high priority max thread is separate from the audio thread and can take advantage of multiple CPUs/cores. I think it's safe to assume that Jitter objects exploit multi-core resources wherever there is a practical solution to the problem of doing so. The equivalent to this for audio is poly~ which offers a basic level of ability to distribute audio processing statically over multiple cores for multiple instances of a patch.

What exactly is it you are trying to optimise?

2 - Most of the time the allocation of threads to CPUs or CPU cores is not handled by end user software, but much deeper in the OS/Hardware system. Before Mac OS 10.4 or 10.5 (I forget which) there wasn't even a way to suggest how a thread should relate to CPU cores on the Mac OS - after that there was a processor affinity option, but even that does not guarantee that a certain thread will always run on a certain CPU core. In other words the model you're dealing with here is assigning things to threads, and allowing the system to divide those between CPUs as appropriate. 

What exactly is it you are trying to optimise? 

From my experience, mxj/java offers a relatively simple and very efficient way of creating a parallel thread that will translate in the use of an other core. I use it mainly with jit_matrix in and out, and having in java a complex processing ( for example fluid processing).

On my double core Macbook pro, within Max thread (MAIN), it brings my qmetro for opengl to 5 fps. With a thread for the fluid/mxj, I can maintain a 30 fps for openGL, and reintegrate an time-interpolated matrix out of mxj (other thread) at 15 fps. Im planning to share this example when i have time.

My conclusion is that mxj/thread is very efficient with complex matrix processing. And it's trans platform. I'm afraid C is much more complicated.

ps: I'm not a programmer, i googled and found thread in java example and adapted it.

From my experience, mxj/java offers a relatively simple and very efficient way of creating a parallel thread that will translate in the use of an other core. I use it mainly with jit_matrix in and out, and having in java a complex processing ( for example fluid processing).
On my double core Macbook pro, within Max thread (MAIN), it brings my qmetro for opengl to 5 fps. With a thread for the fluid/mxj, I can maintain a 30 fps for openGL, and reintegrate an time-interpolated matrix out of mxj (other thread) at 15 fps. Im planning to share this example when i have time.
My conclusion is that mxj/thread is very efficient with complex matrix processing. And it's trans platform. I'm afraid C is much more complicated.
ps: I'm not a programmer, i googled and found thread in java example and adapted it.


It sounds great. Could you share this example? I am very interested on controlling the threads of my opengl patches.

Multiprocessors : distibuting processes on different threads and processors ?