redhexagonal

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?

dual-processor-pcs

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

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. 

But MacbookPro has duo processor and all the model of desktop is dual

processor or dual core. That means that everybody is looking for

> 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

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.

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


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

> 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 

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 

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

Yes, and we've had dual processor G5s and never mind all that multi- 

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.

> In short, my guess is no, MSP does not take advantage of dual CPU 

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.

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.

Peter Castine +--> Litter Power & Litter Bundle for Jitter

Interface Building for |home | chez nous|

Max/MSP Extremely cool |bei uns | i nostri|

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.

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.

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

> 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 

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? 

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).

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).

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?

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

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

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

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

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 ?

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

nick rothwell -- composition, systems, performance -- 

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


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 

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 

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

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

You've posted this as a follow-up to a thread on dual processors, so 

relatively few people will see your message.

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

> 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

https://cycling74.com/story/2005/5/2/133649/9742

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:

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

> nick rothwell -- composition, systems, performance -- 

----------------------------------------------------

>
> 	-- N.
>
>
>    nick rothwell -- composition, systems, performance -- 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

dual processor pcs