Forums > MaxMSP

poly~ multithread bug ?

October 14, 2008 | 2:13 pm

hi list,

can anyone confirm this please ?

i’ve attached an archve with 2 patchs : parabug.maxpat and
parabugparent.maxpat

- launch max, be sure audio is off.
- load parabugparent.maxpat (wait 1 second, loadbang is delayed)
- turn audio on, you will see this error message
- turn audio off, max freezes

i’m on mac intel, os x 10.5.

thanks

g


October 14, 2008 | 2:17 pm

oops

"this error message" = "our pool count isn’t zero (1), must be calling from
the wrong thread … living dangerously"

sorry

g

2008/10/14 Guillaume Evrard

> hi list,
>
> can anyone confirm this please ?
>
> i’ve attached an archve with 2 patchs : parabug.maxpat and
> parabugparent.maxpat
>
> – launch max, be sure audio is off.
> – load parabugparent.maxpat (wait 1 second, loadbang is delayed)
> – turn audio on, you will see this error message
> – turn audio off, max freezes
>
> i’m on mac intel, os x 10.5.
>
> thanks
>
> g
>


October 15, 2008 | 12:45 am

The attached patch (which can only be found by looking in the archives) demonstrates an incorrect use of multi-threading. Both the parent poly~ and the nested poly~ are set to parallel, which will make no difference in performance over just having the outermost poly~ set to use multi-threading (think about it for a second) and currently leads to the problems you reported. Simply don’t use parallel on the innermost poly~ and you’ll get all the performance benefits of multiple threads.

You can use any number of poly~ objects at the same level and set them to use multi-threading, but you cannot embed multi-threaded poly~ objects inside of other multi-threaded poly~ objects.

In the next update we will protect against this use of parallel and report an error while also automatically adapting processing to occur in a non-parallel fashion. The parallel message has also been made into an attribute.

David Z.


October 15, 2008 | 1:02 am

hi david

thanks for your answer, this patch was part of a serie of tests i made about
poly~. that’s quiet logic that if the parent poly~ is set to parallel 1,
childs shouldn’t need it.
but it had to be tested.

and thank you for making the parallel option an attribute.
did "threadcount" also become an attribute?

cheers

g

2008/10/15 David Zicarelli

>
> The attached patch (which can only be found by looking in the archives)
> demonstrates an incorrect use of multi-threading. Both the parent poly~ and
> the nested poly~ are set to parallel, which will make no difference in
> performance over just having the outermost poly~ set to use multi-threading
> (think about it for a second) and currently leads to the problems you
> reported. Simply don’t use parallel on the innermost poly~ and you’ll get
> all the performance benefits of multiple threads.
>
> You can use any number of poly~ objects at the same level and set them to
> use multi-threading, but you cannot embed multi-threaded poly~ objects
> inside of other multi-threaded poly~ objects.
>
> In the next update we will protect against this use of parallel and report
> an error while also automatically adapting processing to occur in a
> non-parallel fashion. The parallel message has also been made into an
> attribute.
>
> David Z.
>
>
>
>


October 15, 2008 | 7:29 am

Hey, it’s late, I’m gonna act the fool a bit. (12 hour workdays, woohoo!)

What happens if I make [poly~ polypatch 24], and the polypatch patch contains a [poly~ polypatch 24] object? Do I win the game? Final boss defeated?

Or, if that’s too obvious, how about three patches, one containing [poly~ polypatchA 24], polypatchA containing [poly~ polypatchB 24] and polypatchB containing [poly~ polypatchA 24]?


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