In short, my guess is no, MSP does not take advantage of dual CPU computers from what I understand. Of course, I’d like to be told otherwise =P

binez0r

K

On 7/23/06 5:55 PM, “binez0r” wrote:

>
> Hrm, don’t think max supports dual processors. If it did it would go against
> the logic of the single signal network I’ve come to understand MSP works under
> [with the exception of poly~ incurring new threads I believe]… still
> exploiting max and my hardware gear so I really am just trying my best here
> since there hasn’t been a response yet.
>
> In short, my guess is no, MSP does not take advantage of dual CPU computers
> from what I understand. Of course, I’d like to be told otherwise =P
>
> binez0r

Select Max/MSP in the Finder. Duplicate. Launch Max/MSP and Max/MSP
Copy and Max/MSP Runtime and a Max/MSP-standalone. You now have four
instances running.

On 23-Jul-2006, at 13:39, Koutaro fukui wrote:
> But MacbookPro has duo processor and all the model of desktop is dual
> processor or dual core. That means that everybody is looking for
> multiprocessor support.

Yes, and we’ve had dual processor G5s and never mind all that multi-
proc XP hardware.

But I’m not at all sure that the MSP architecture is at all conducive
for splitting processing up across different processor. When you turn
MSP on, what it does is to compile a DSP processing chain. You get
something like “tell phasor~ to generate a vector of samples, pass
that vector to a cycle~’s right inlet, take the vector that cycle~
generates and pass it to biquad~, let biquad~ do its thing and pass
that on to the left inlet of a [*~ 0.2], then send the output vector
on to the left and right inlets of a dac~.”

How is that supposed to be sensibly shared between two processors?
Unless MSP has logic for recognizing that two sections of the DSP
chain are completely independent, which I don’t think it can do. Yet.

As Deep Thought said, “Tricky.”

On 23-Jul-2006, at 10:55, binez0r wrote:
> In short, my guess is no, MSP does not take advantage of dual CPU
> computers from what I understand.

I’m a little puzzled by this thread as a whole since it has been
addressed by people from Cycling ’74 in the past. Basically,
binez0r’s guess summarizes the official response to the question.

MSP audio processing is one processing thread.
Max scheduling is one processing thread.
Jitter, if it’s on, is one processing thread.
There may be a couple of other threads running.

A processing thread cannot be split between multiple processors.
Different processing threads can, as I recall, be distributed over
multiple processors. This is indeed happening with Max/MSP, but often
the MSP thread is the real bottleneck and that’s the end of the story.

– P

————– http://www.bek.no/~pcastine/Litter/ ————-
Peter Castine +–> Litter Power & Litter Bundle for Jitter
Universal Binaries on the way
iCE: Sequencing, Recording &
Interface Building for |home | chez nous|
Max/MSP Extremely cool |bei uns | i nostri|
http://www.dspaudio.com/ http://www.castine.de

if i copy the max msp application, and open one synth patch in each of the 2 max msp applications(creating 2 MSP audio threads), i will be able to take advantage of a dual processor machine, and be able to get more polyphony, for instance, than if i ran two synth patches in one instance of the max msp application(which creates one MSP audio thread).

I’m guessing the assignment of an audio thread to a particular processor is done by the OS rather than by MaxMSP?

sorry if i’m being thick.

That is my understanding of the situation as it stands.

BUT: don’t expect a dual processor running two instantiations to give
you twice the audio. That second processor is not twiddling it’s
thumbs while running one Max/MSP instantiation: it’s already busy
with the Max scheduler and a bunch of stuff the OS is running.

Oh, while we’re getting things straight: if you have two instances of
Max running, don’t expect a [send~ foo] in the one to find a
[receive~ foo] in the other. Cf. Matthew VI:3. Ditto for any other
symbol-based communication. You can probably get synchronization
going with mxj net.* stuff addressed to localhost, though.

> I’m guessing the assignment of an audio thread to a particular
> processor is done by the OS rather than by MaxMSP?

The OS does most of the work in handling threads: allocating
processor access, preempting one thread in favor of another,
distributing threads across processors, etc. This is just one of the
things an OS like Unix does (or should do).

So, yes. Just the “yes” is not limited to audio threads.

—

For all the groanin’ and moanin’ that “MSP doesn’t support dual
processors,” I would be curious to know which DSP apps *are* able to
actively split audio processing across processors. Reaktor? Logic?
ProTools? CSound?

————– http://www.bek.no/~pcastine/Litter/ ————-
Peter Castine +–> Litter Power & Litter Bundle for Jitter
Universal Binaries on the way
iCE: Sequencing, Recording &
Interface Building for |home | chez nous|
Max/MSP Extremely cool |bei uns | i nostri|
http://www.dspaudio.com/ http://www.castine.de

just happen to come across the first one I know of….

http://www.ableton.com/pages/live_6/whats_new/home

-thijs

or am i swallowing some silly marketing trick ?

> Max scheduling is one processing thread.

Well, there’s the GUI thread and the (overdrive) scheduler thread…

– N.

nick rothwell — composition, systems, performance — http://
http://www.cassiel.com

> Oh, while we’re getting things straight: if you have two instances
> of Max running, don’t expect a [send~ foo] in the one to find a
> [receive~ foo] in the other.

OSC should work, though, or (as Peter says) networking via MXJ. Or
even IAC MIDI, for those who like retro solutions. Or I suppose one
could adopt an “analogue computer” solution and communicate between
the applications using audio signals…

> Cf. Matthew VI:3.

Indeed; but on the third hand…

– N.

nick rothwell — composition, systems, performance — http://
http://www.cassiel.com

> I would be greatful for some help.

You’ve posted this as a follow-up to a thread on dual processors, so
relatively few people will see your message.

– N.

nick rothwell — composition, systems, performance — http://
http://www.cassiel.com

Interesting topic. There is no real documentation available about this issues except for joshua’s article

http://www.cycling74.com/story/2005/5/2/133649/9742

This doesn’t cover everything though.

What I understood is that there is no separate gui thread and no separate jitter thread. Both are part of the low priority queue together with all other non-MSP objects. This means for example that rapidly updating GUI elements have a direct effect on the jitter framerate. We’ve had a thorough discussion about that here:

http://www.cycling74.com/forums/index.php?t=msg&rid=3579&S=16c6e8d77f637b780a8f1b9696ef361d&th=20421&goto=73566#msg_73566

Mattijs

>
> – N.
>
>
> nick rothwell — composition, systems, performance — http://
> http://www.cassiel.com
>
>
>
>
—————————————————-

is a single dual core processor going to behave the same way as two separate processors on one motherboard? ie can i ran two instances of maxmasp on one dual core chip, with an audio thread going to each of the two elements of the chip?

i’m trying to work out which chip(s)/motherboard to purchase