I have to say....it's remarkable how often I find the answer to my question while composing it or within minutes of posting it. Apparently send~/receive~ doesn't work at block sizes other than 64, and one should use tabsend~/tabreceive~ instead. Not sure how I stumbled across this post from 8 years ago. I do think the [block~] help file is misleading though.

I'm trying to make an abstraction that toggles between 1 and -1 at audio rate whenever its input decreases, so I came up with this:

I reduced the block size in the hope that it would reduce the delay of send~/receive~ to 32/44100 seconds, but I'm getting the following errors:

receive~ 1011_nextVal: vector size mismatch
sigsend 1011_nextVal: unexpected vector size

I was lead to believe this should work from the [block~] help file:

"Patches using send~/receive~ or throw~/catch~ to intercommunicate must have the same blocking -- and if their parents are blocked bigger than they are, there might be weirdness."

Am I doing something wrong?

@jancsika So now of course I can't seem to generate another junk error message. The closest I've gotten so far is a long string of spaces. Here are both the Pd parent window as well as the terminal output.

pdwindow2.txt
Pd debug level 3 output2.txt

I don't see that long string in the terminal output, but I do see a sequence of 4 unterminated pdwindow::post calls at line 278 and another one at line 312.

Bingo! I reproduced the error on my ancient Lenovo and got the following error message: Note the noise in the command string. This has got to be helpful to a developer, no?

@jancsika OK, I fell back to my last broken, half-minimized version (the one without David's loadbang delays), unchecked the verbose box in Pd->Preferences->Path...(not sure if that's really the least verbose level, but that's what I did) and suddenly everything works, and there are no messages in the parent window, error or otherwise. So I didn't try your "-d 3" flag suggestion.

I still don't know if the problem is reproducible on other Macs though. Would someone be willing to give it a try? player.zip Unzip it to some folder, run [player.pd], try to move any of the vertical sliders, and look for an error message in the parent window. Try with verbose checked and unchecked. On my machine with verbose checked, the vertical sliders look like they're not moving, but they actually are. If I click anywhere on the fader then click the upper right toggle, I hear the corresponding sound file.

@whale-av RE those arrays in the main window: they're not real. They can't be selected, opened or deleted. They're just graphic junk copied from some of the abstractions. So those $0s are not an issue--they're just plain local variable names that for some reason are being shown in the calling patch.

RE loading the same file over and over: remember, this is the code branch where I'm trying to find a minimal patch that still exhibits the original issue. I used to have a big initialization subpatch that sent unique filenames (among other data) to each abstraction. I got rid of it to see if the problem persisted (it did) and to avoid having to include 32 unique sound files in the event that I file a bug report.

RE [loadbang]->[delay $1]->...: yes, that's exactly what I did, which is why I asked you how far apart you separated your loadbangs.

Please don't read too much into that snapshot I posted. There's lots of stuff in it that no longer serves any purpose which I either haven't gotten around to removing, or seems to be required to reproduce the error.

@whale-av Good idea! On the Mac, I still get the error message, but at least now the patch UI has unfrozen. On Windows, the arrays from some of the abstractions are now erroneously being drawn in the main window.
How far apart do you space your loadbangs? What kinds of problems are you addressing when you have to do that?

@jancsika
I just now noticed that this window will not scroll.

@Nicolas-Danet I would like to, but I'm having a hard time understanding what constitutes a helpful, minimal patch in this case. The issue occurs right when the patch is loaded and it freezes the UI 95% of the time. If I disable the loadbangs it goes away. If I delete other objects instead, ones not involved with loadbang initialization, the patch starts working with higher and higher probability, and when there's about a 50% chance that the error will occur, the error message identifies a different line on each invocation.

Adding to the confusion, I went back and tested the main branch of my code, the one that I was continuing to develop assuming I'd have to run it on my windows laptop, and now that version runs brilliantly on the Mac--loads consistently, can be adjusted for very low latency without stuttering, etc. So it would not surprise me if this issue is related to the speed of my hardware, since it appears to be contingent on the time it takes to load and initialize the patch. It's as if there's a short window of time during start up where some object is being used before it has been fully initialized.

@Nicolas-Danet Thanks, that definitely opened a console window, but it looks like the error is being caught and redirected to the PD window because the console is empty except for "() 1 %". So maybe what I'm seeing is the full (unhelpful) error message....