Forums > MaxMSP

dual processor pcs

July 22, 2006 | 1:32 am

i cant quite make out from the archives, what happens if i have say two MSP synth patches running on a dual processor pc. does each patch run its own audio thread, on separate processors? or is the whole running MAX/MSP application calculted as one audio thread? is there a way of making each patch run on a sparate processor?


July 23, 2006 | 8:55 am

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


July 23, 2006 | 11:39 am

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.

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


July 23, 2006 | 11:58 am

i’m sure i read that different instances of Max MSP could make their own audio threads on separate processors, but i’m not sure what an "instance" meant


July 23, 2006 | 3:45 pm

On 23-Jul-2006, at 13:58, bin ray wrote:
> i’m sure i read that different instances of Max MSP could make
> their own audio threads on separate processors, but i’m not sure
> what an "instance" meant

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


July 23, 2006 | 4:13 pm

let me get this straight…

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.


July 23, 2006 | 4:48 pm

On 23-Jul-2006, at 18:13, bin ray wrote:
> let me get this straight…
>
> 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).

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


July 23, 2006 | 6:29 pm


July 23, 2006 | 7:29 pm

On 7/23/06, Peter Castine

wrote:
>
>
>
> 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?
>

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

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

-thijs


July 23, 2006 | 9:15 pm

logic does too. one soft synth will show up on one of the cpu load graphs, while the other does nowt until you bring in, say, a second synth.

or am i swallowing some silly marketing trick ?


July 23, 2006 | 11:06 pm


July 23, 2006 | 11:38 pm


July 24, 2006 | 11:41 am

On 23 Jul 2006, at 17:45, Peter Castine wrote:

> 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


July 24, 2006 | 11:47 am

On 23 Jul 2006, at 18:48, Peter Castine wrote:

> 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


July 24, 2006 | 11:49 am

On 24 Jul 2006, at 01:06, Vangelis L wrote:

> 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


July 24, 2006 | 12:23 pm

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

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
>
>
>
>
—————————————————-


July 24, 2006 | 2:49 pm

while were at it….

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


Viewing 17 posts - 1 through 17 (of 17 total)