Using a low vector size, scheduler in overdrive, and audio interrupt uses a large amount of CPU, but it seems to be getting the results/accuracy I am after. Is there an equivalent high CPU high precision mode in PD, and how do I enable it?
-
Max's vector size/scheduler overdrive/audio interrupt equivalent?
-
So then... what about things happening simultaneously... and possibly sample-accurate? Is that never a guarantee on PD or Max?.. I guess Max has Gen so that might solve the problem.
-
Still not sure about Max/MSP's vector size... but if you need a chain of objects in your patch to do computations with a blocksize of 1, just use [block~ 1] inside a subpatch. The xlets feeding in and out will convert to/from the main patch's block size of 64.
-
SOO..... if you can just set block~1, then why do I see a lot of complaints about things not being sample-accurate in PD? Is that simply because some objects can go as low as 1 block, and others can't?
-
There may be several reasons for those complaints:
* the frustrated patch author may be passing data between the control and signal domain, which has a more complicated dataflow than a patch where the data stays in the signal domain
* it takes more CPU to compute 64 blocks in a subpatch with a [block~ 1] than it does to compute a single block of 64 samples. For complex patches, throwing everything in a [block~ 1] subpatch could very quickly eat up all of your resources. (After all, if the two approaches were equally efficient you could just do everything in the control domain.) -
Actually I'm not sure about that part in the parentheses. I believe the signal graph is computed by iterating through an array of function pointers, while the control domain walks through a bunch of linked lists of outlets. I'd expect the former to have a lot less overhead.
-
@jancsika said:
For complex patches, throwing everything in a [block~ 1] subpatch could very quickly eat up all of your resources.
Sweet, because that's exactly what I want.
How much of an 8 core CPU can PD make use of? Seems like Max/MSP can't make use all my CPU.
-
Well, I'd suggest isolating only those parts of your patch that require a smaller block size, and putting them in a subpatch with [block~ 1]. Otherwise Pd will be doing 63 more function calls for every single signal object in your patch.
Pd doesn't do automated parallelism. You can spawn child Pd instances using the [pd~] object.
-
so I was really thinking I would not go and buy Max because PD is clearly more practical for what I want to do, but I've hit a roadblock... with block... pun intended.
I can't get sigmund to function below a hop size of 64. The hop size can only be as low as the block size. So I put [block~ 32] and set hop size to 32, and sigmund stops working, even though giving a print command reveals it is correctly set to a hop size of 32. If the [block~] is 64, and you put hop of 32, then sigmund shows a hop size of 0 (means it's REALLY not working).
ugh, so frustrating! I thought this would be the ONE thing I could depend on.
hmm, no attachment function? alright.
http://www.elanhickler.com/transfer/sigmund_timer_tester.pd
please see if this patch works, just hit the metro on button.
I just want to get sigmund ultimately to work at a hop size of 8. It works fine in max. :\Edit: I'm getting this error if this helps at all
"conflicting block~ objects in same page
vd~: vd~: no such delwrite~" -
Sorry, I've only used [sigmund~] in patches with the default block size. You should ask on the Pd mailing list.