• jameslo

    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.

    posted in technical issues read more
  • jameslo

    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:
    toggler.JPG
    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?

    posted in technical issues read more
  • jameslo

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

    posted in technical issues read more
  • jameslo

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

    posted in technical issues read more
  • jameslo

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

    posted in technical issues read more
  • jameslo

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

    posted in technical issues read more
  • jameslo

    @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.Capture.JPG
    How far apart do you space your loadbangs? What kinds of problems are you addressing when you have to do that?

    posted in technical issues read more
  • jameslo

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

    posted in technical issues read more
  • jameslo

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

    posted in technical issues read more
  • jameslo

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

    posted in technical issues read more

Internal error.

Oops! Looks like something went wrong!