I'm investigating a patch that's misbehaving on a Mac (but weirdly, not on Windows 7 or 10), and am seeing the following message in the parent window when it fails:

There's got to be more error text somewhere--how can I view it?

@jameslo You could try delaying your loadbangs in each abstraction, or use a master loadbang with delays in your main patch to send message bangs to receivers where previously you have loadbangs to bang them in a sequence..... if that makes sense.
I have sometimes had to do that with really massive patches.
David.

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

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

What happens if you change the log level to the least verbose level? Does it print out the entire error?

If not, try running pd from the command line with the "-d 3" flag. That will make it print every message to and from Pd/GUI to the command line. Then you can look at the most recent printout to the command line to try to figure out what is triggering the error. (Note, however, that every mouse movement on a canvas will trigger command line output, so try to avoid interacting at all with the patch when you look at the command line output.)

@jameslo Spacing each loadbang for me has been trial and error..... to get a patch to work.... although you have to think the patch through in terms of "what" should load before "what".
I see you using [catch] but no "no corresponding catch" messages so maybe not the problem.

In the windows patch the arrays are strange? If you open them is there actually anything inside? I doubt it. The $0 has not been translated in their names, and they are exact copies of each other (all the "left" are the same and all the "right" are the same)...... unless the $0's are different having been drawn from separate abstractions with different $0 values. Again, I doubt that is the case looking at your screenshot.. But if they are different it must be a load timing issue again. The OS might need a little more time to re-read the file repeatedly.

So there is probably one that has created correctly, and the others cannot because they have the same name, or none have created because an I/O read was abandoned as a request to read again was received. Actually that is likely?? Read the same file again.... well, I will cancel the last read then!!... might be the response from the OS, and might be different depending on which OS it is, and whether it has an SSD or a hard drive. All OS's will treat media files differently than other file types. They often load just the header and a few Mbytes of media and wait for instruction to continue.

That is (maybe) where the problem lies, especially as the error prints just after loading the exact same wav file numerous times.
If the $0's are all the same then you should find that giving them $1 names instead of $0 will solve the problem.

You could try printing each loadbang in your sequence to the terminal (with an identifier) to narrow down the exact moment or the error, but I am pretty sure it is that $0, or a "read the file again" issue.
David.

@jameslo PS...... is there a reason not to read the audio into just one array, and then point all the players to that one array? They can all read it at the same time, so normally they would not need a copy each...... unless the arrays are modified by the patch during later operation.
And unless of course trying to write it over and over again is actually a problem caused by the error, and was never your intention.

As your players seem to have a $1 value you could load the audio into each one from a loadbang like this.
[loadbang]
[delay $1]
[open xxxxxxxxxxxxx.wav(
David.

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

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

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?

@jameslo AhHH..... totally misunderstood.
I am away for a few days in the "frozen" North (-14C) with no time to check your patch until next week. Someone else probably will though.
Frozen faders that are really moving (in the window below) I have had with complex patches and I think I wrote about it on this forum years ago. I can't for the life of me remember my conclusion or solution though.
I will post if I find it on my laptop but it is probably on the server at home.

But but but..... WOW..... how great is the internet.
https://forum.pdpatchrepo.info/topic/8226/dynamicaly-created-gop-s-frozen-until-child-opened-the-first-time
Even Dementure might not see the back of me.
And also maybe the "uplevel" error is meaningful for your patch after all.

So maybe write your entire patch into a sub-patch, so that it is not drawn as it is created, and then send it the vis 1 message once all is loaded.
David.

@jameslo Now that you've got more error output, try adding the "-d 3" flag to the startup flags. Keep it in verbose mode.

Then when you trigger the error, scroll back in the command line terminal until you find the same garbage that is quoted in the error in the Pd console.

Paste a chunk of that output which surrounds the garbage somewhere so we can inspect it.

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

That's some fairly nasty corruption.

The printout for the "-d 3" flag happens in the core process. Since it doesn't show the same charset corruption that you get in the Pd console, I'd guess that something either in the socket sender or the tcl receiver is corrupting the data.

If I had to guess, I'd say memory corruption somewhere in the s_inter.c code that sends a buffer of data off to the GUI over the socket. I'd also guess the problem lies in a branch of code that doesn't get triggered until Pd collects more data to send to the GUI than can fit in a single packet. In any case, valgrind can probably help pin it down.

If you want, you can try running your patch in Purr Data:

https://github.com/jonwwilkes/purr-data/releases

If you still get a similar problem, then this is probably a bug that's been around for awhile.