I'm trying to send some signals around a reblocked patch, and I'm getting the following errors:
error: sigsend 1002-test: unexpected vector size error: receive~ 1002-test: vector size mismatch
this happens in a simple test patch with a send~/receive~ pair inside of a subpatch that's reblocked to any size except 64. What's up?
I'm using PD-extended 0.39.3 from Hans's installer on Ubuntu Gutsy
oops, sorry for double reply spencer..forgot to send this mail to the list.
the [send~] & [receive~] objects only work for default block size.
you can create a table the same size as your new blocksize, and use [tabsend~] / [tabreceive~], although i think that might bring in a one block delay, which might not be what you want.
On Tue, 2008-03-18 at 17:17 +0900, hard off wrote:
oops, sorry for double reply spencer..forgot to send this mail to the list.
no problem. I get the digest, so this sped up the process, anyways! :)
the [send~] & [receive~] objects only work for default block size.
hmm, the block~ documentation only seems to say that the blocking must be the same if you're send~ing across subpatches, which I assumed meant that sending within a reblocked subpatch would be OK. Is there a technical reason for this limitation?
you can create a table the same size as your new blocksize, and use [tabsend~] / [tabreceive~], although i think that might bring in a one block delay, which might not be what you want.
I could also use a delwrite~ and a delread~, which shouldn't introduce a delay if I force dsp calculation order using other subpatches. Just a little less clean.
thanks! -spencer
On Tue, 2008-03-18 at 01:26 -0700, Spencer Russell wrote:
On Tue, 2008-03-18 at 17:17 +0900, hard off wrote:
oops, sorry for double reply spencer..forgot to send this mail to the list.
no problem. I get the digest, so this sped up the process, anyways! :)
the [send~] & [receive~] objects only work for default block size.
hmm, the block~ documentation only seems to say that the blocking must be the same if you're send~ing across subpatches, which I assumed meant that sending within a reblocked subpatch would be OK. Is there a technical reason for this limitation?
actually i thought the same, but i had a look at send~-help.pd again, and it clearly says, that [send~]/[receive~] pairs are only wokring with a blocksize of 64 (updated last time for 0.33)
you can create a table the same size as your new blocksize, and use [tabsend~] / [tabreceive~], although i think that might bring in a one block delay, which might not be what you want.
from my tests, it seems, that a block delay is not avoidable with tables.
I could also use a delwrite~ and a delread~, which shouldn't introduce a delay if I force dsp calculation order using other subpatches. Just a little less clean.
i found something interesting here. i was trying to find a solution, but couldn't find something else than using [delwrite~]/[delread~] pair. however, the interesting part is, that you only can get 0 delay, if you really put them in separated subpatches wich are connected. even if the creation order of [dekwrite~] and [delread~] is correct, the delay is one block. or if you cut the connection between the two subpatches, the delay jumps to one block again. and also make sure, to give [delwrite~] at least a buffer of one block size~. [delwrite~ bla 0] doesn't work, even if the resulting delay is 0ms.
roman
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de
-
hard off -
Roman Haefeli -
Spencer Russell