Hello,

I'm trying to create a modulation matrix for my patch, where I can route a bunch of control signals (LFO, ADSR, etc) to modulate various parameters using a matrix mixer topology (all mod sources can be sent to all destinations, and all destinations can receive a mix of all sources). I am naturally going for the [throw~] and [catch~] object to create one summing bus per destination (16 in total).
But I run into some errors there:

throw~ MO_pulse-width_mod: vector size mismatch
sigcatch summingBus1: unexpected vector size

I have figured out this has to do with DSP block size conflicts, as I have [block~] objects of varying sizes in several sub-patches. However I cannot get my head around DSP block size handling in Pd, and even less how to solve my issue. I have tried putting a number of size-matching [block~] objects on the subpatches containing the [throw~] and [catch~] objects and/or, where the source signal is actually being generated. None worked.

However, I noticed that if I replace [throw~]/[catch~] by {send~]/{receive~] and put a [block~ 64 1 1] in both sub-patches, the conflict is resolved. But using {send~]/{receive~] would greatly complexify the patch so I'd rather stick with [throw~]/[catch~] if I can.

I have tried to draw an accurate hierarchy of my current patch in the hope you may help me figure out where the mismatch occur. It's a tad complex as the modulation sources, the matrix mixer and the modulation destinations are all in different places of my patch. So I'm first using [s~] objects to send the various mod sources to the mod matrix, then use [throw~] objects to send these to the various "destinations" summing buses. I have added info where the signal generators are (~), [s~]/{r~] and {throw~/catch~] are all located in the hierarchy, as well as where some mandatory [block~] objects are (I cannot remove these as it will break my code).
Here it is:

Hope my post and this graph somehow makes sense...

@tomatoKetchup http://puredata.info/docs/manuals/pd/x2.htm Chapter 2.4.5
Sorry that it's bad news...... you will have to use inlets and outlets and then connect those to your [throw~] or [catch~]
The best way to deal with this is to always put the blocked part of an abstraction into a sub-patch...... give the sub-patch inlets and outlets which will re-block to 64 for the abstraction...... and then use [throw~] and [catch~] to connect to the other abstractions.
David,

@whale-av I'm not sure I quite get it, even after reading the chapter and your post. Isn't it already what I'm doing there?
For instance, all my [throw~] are in the SrcX routing subpatches, and all my [catch~] too (related to the reblocked Subpatch1). Yet I'm still getting the error message.
I have screenshot a throw/catch pair of subpatches embedded with inlet~/outlet~ connections below:

@tomatoKetchup I think subpatches and abstractions inherit the blocking of their enclosing patches unless specified otherwise. Try explicitly declaring a 64 sample block size in the subpatches containing the throw and catch objects and see if that fixes things.

@jameslo When I do that I get no signal (the PWM does not work). I've tried tabwrite~ing both before the throw~ and after the catch~ and this is what I get:

@tomatoKetchup Here's an example of what I was thinking:

reblockingTest.pd

@jameslo ok thanks, making some progress. Following your example, I've removed the [block~] object in the throw~ subpatch (I figure there's no need since none of the parent patches are being reblocked) and then changed the block~ in the catch for [block~ 64 1 0.25] (0.5 didn't work, probably because the parent was reblocked at 256, not 128 like in your example).

It seems to work and I've no more error messages, which is good. But there's a very strange new glitch in that the catch~d signal is somehow twice the amplitude of the one being throw~d (it oscillate between -2 and +2). Why would that be in your opinion?

EDIT: got it. My reblocked parent patch needed to be [block~ 256 1 4]. I gather the signal was sent twice between each new blocking of the receiver, hence appearing as if 2 identical signals were being mixed.

I hope changing this to 4 won't somehow break the code I had running already. Will have to do some heavy testing now to make sure the rest of the patch still behaves correctly.

Everything seems to be working fine, fantastic! A great thanks to both of you @whale-av and @jameslo for the help!

@tomatoKetchup That's good news.....!
For others.... this is how to do it...... patch.pd
David.