@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....

@LucienR No, but the only other device I've tried is the Yamaha 01V96i.

@whale-av Yikes! Bash shell! Anyway, I verified that that instance you identified is the only one that contains "uplevel #0 $docmds" but it seems like the switch statement in the else clause immediately following that ought to have at least added "(Tcl) UNHANDLED ERROR" but that's just me reading it as though it were C#/Java/C++.