Guillaume Evrard

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

- load parabugparent.maxpat (wait 1 second, loadbang is delayed)

- turn audio on, you will see this error message

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

poly-multithread-bug

"this error message" = "our pool count isn't zero (1), must be calling from

> i've attached an archve with 2 patchs : parabug.maxpat and

> - load parabugparent.maxpat (wait 1 second, loadbang is delayed)

> - turn audio on, you will see this error message

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

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

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.

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,

and thank you for making the parallel option an attribute.

did "threadcount" also become an attribute?

> 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

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?

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

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

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


poly~ multithread bug ?