Hello,
I have just discovered a nasty bug!
Just DL the attached file and try it out yourself...
This seems to be a bug with pd's "dsp-compiler" or whatever it is.

It seems that different blocksizes are combined "randomly"...

One could do some statistics on this situation to see what's going on.
I guess the quotient of the two different blocksizes gives the chance to get correct results instead of the buggy ones.
So for [block~ 16 1 1] and [block~ 64 1 1] I'd get a chance of 16/64 = 0.25 => 25% to get good results.

Plz try it and share your results, maybe me (or my PC) are the bugs here and not Pd.
..and does someone know what happes to the dsp-line when switched off and on?!?

http://www.pdpatchrepo.info/hurleur/BlockBug1.pd

ahh. i see what you mean. yeah, the block phase changes when you edit the patch, or turn dsp on and off..

not sure if there's any way around that.

strange... what pd-version do you use and on which OS? I use pd-0.42.5-ext on windows..
And I get these printouts:
If it works:
c:
0 0.1 0.2 0.3 0.4 0.5 0.6 0.7
0.8 0.9 1 0.1 0.2 0.3 0.4 0.5
0.6 0.7 0.8 0.9 1 0.1 0.2 0.3
0.4 0.5 0.6 0.7 0.8 0.9 1 0.1
0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9
1 0.1 0.2 0.3 0.4 0.5 0.6 0.7
0.8 0.9 1 0.1 0.2 0.3 0.4 0.5
0.6 0.7 0.8 0.9 1 0.1 0.2 0.3
b:
0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0
a:
0 0.1 0.2 0.3 0.4 0.5 0.6 0.7
0.8 0.9 1 0.1 0.2 0.3 0.4 0.5
0.6 0.7 0.8 0.9 1 0.1 0.2 0.3
0.4 0.5 0.6 0.7 0.8 0.9 1 0.1

and if it is "buggy" (after switching dsp on & off a couple of times):
b:
-0.79831-0.79831-0.798310.20169 0.20169 0.20169 0.20169 0.20169
0.20169 0.20169 0.20169 -0.79831-0.798310.20169 0.20169 0.20169
0.20169 0.20169 0.20169 0.20169 0.20169 -0.79831-0.798310.20169
0.20169 0.20169 0.20169 0.20169 0.20169 0.20169 0.20169 -0.79831
a:
0 0.1 0.2 0.3 0.4 0.5 0.6 0.7
0.8 0.9 1 0.1 0.2 0.3 0.4 0.5
0.6 0.7 0.8 0.9 1 0.1 0.2 0.3
0.4 0.5 0.6 0.7 0.8 0.9 1 0.1
c:
0 0.1 0.2 0.3 0.4 0.5 0.6 0.7
0.8 0.9 1 0.1 0.2 0.3 0.4 0.5
0.6 0.7 0.8 0.9 1 0.1 0.2 0.3
0.4 0.5 0.6 0.7 0.8 0.9 1 0.1
0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9
1 0.1 0.2 0.3 0.4 0.5 0.6 0.7
0.8 0.9 1 0.1 0.2 0.3 0.4 0.5
0.6 0.7 0.8 0.9 1 0.1 0.2 0.3

"b" shows the PWM... and notice the changed order of the printouts...

Please try again with a lower blocksize of the subpatch (..like [block~ 4 1 1]..) or maybe a higher blocksize of the sub-sub-patch (..like [block~ 256 1 1]..).
Isn't PD quite "standalone", I mean there is no deep "coupling" to the OS ?! So can this really just be my personal bug???

...Ah Ok, glad Im not the only one! ...didn't see ur post while writing...

if it's really bugging you, maybe try the mailing list, as there are a few people on there with more knowledge of the source code.

the printouts will occur after the end of each block, so if the block order goes out of sync, the printouts should naturally go out of sync too.

unless there is something you really need to keep blocks in sync for, then you might find a workaround. For example, in this case, having 2 phasors in different blocks...why not just send the output of the first phasor~ into the subpatch?

I never used this mailing-list, can't you or someone do that, and guide people with knowledge to this page, plz?!?
Btw. why don't we have a BUGs-section on this Forum?? There are more bugs but they "disappear" in the "technical issue"-section, as far as I can see. And maybe we would have more developers around...

If I got you right, this workaround doesn't work. I tried to get the 1st phasor's signal into the sub-sub-patch via "cable" and via "s~/r~" or "tabsend~/tabreceive~" but the results are exactly the same!!!
This really seems to be a "randomly phaseshifted dsp-block-thing" but as far as I know there natively is no "randomness" in the digital world...

If you don't want to use the mailing list, file a bug report. There's a link in the help menu. There's no Bugs section here because the developers don't come here much. It wouldn't do much to help.

sorry, i assumed if you got this far, you'd know how to use google:

"pd mailing list" first result:

http://lists.puredata.info/listinfo/pd-list

i've tested it and i also experienced the error. but it doesn't come up so often. when i switch dsp on/off 20 times maybe i get one asynchron frame.
it's curious indeed.