Hi,
a colleague of mine has frequent freezes of a recent Pd's gui on her Windows computer. It's of the type where depressed message boxes retain their thicker/darker box border. Audio continues to work, the patch can still be saved but no longer interacted with graphically using mouse and keyboard. Is such a behavior known? Thanks! P
Just to be clear, you are talking about Pd 0.51-4 and not the Pd master branch on GitHub, right?
On 11.11.2021 21:45, Peter P. wrote:
Hi,
a colleague of mine has frequent freezes of a recent Pd's gui on her Windows computer. It's of the type where depressed message boxes retain their thicker/darker box border. Audio continues to work, the patch can still be saved but no longer interacted with graphically using mouse and keyboard. Is such a behavior known? Thanks! P
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
- Christof Ressi info@christofressi.com [2021-11-11 21:49]:
Just to be clear, you are talking about Pd 0.51-4 and not the Pd master branch on GitHub, right?
Afaikt, it is 0.51-4 vanilla, yes. Thanks, P
On 11/11/2021 6:06 PM, Peter P. wrote:
Afaikt, it is 0.51-4 vanilla, yes.
Please double check. Tell us if it is the "test" version from http://msp.ucsd.edu/software.html
Menu: help/about Pd
--
Mensaje telepatico asistido por maquinas.
- Lucas Cordiviola lucarda27@hotmail.com [2021-11-11 22:53]:
On 11/11/2021 6:06 PM, Peter P. wrote:
Afaikt, it is 0.51-4 vanilla, yes.
Please double check. Tell us if it is the "test" version from
Thanks Lucas, no -test version, just 0.51-4 Do you think we should try that test version?
best, P
On 11/12/2021 12:33 PM, Peter P. wrote:
Do you think we should try that test version?
I would say skip testing 0.52-0test1 on Windows. The overhaul of the audio engine will hopefully be Ok on "test2" for Windows.
But if "the tester" can live with a fragile "Audio back-end" just go ahead. The majority of the new stuff to test is unrelated to audio.
The known bug on "test1" for Windows is that you can't accurately set "block size" and "delay" in audio prefs.
going back to your original question:
the patch can still be saved but no longer interacted with graphically using mouse and keyboard. Is such a behavior known?
She should carefully check the patch.
Can a patch that triggers the freeze be submitted?
--
Mensaje telepatico asistido por maquinas.
Dear Lucas,
- Lucas Cordiviola lucarda27@hotmail.com [2021-11-12 19:29]:
On 11/12/2021 12:33 PM, Peter P. wrote:
Do you think we should try that test version?
I would say skip testing 0.52-0test1 on Windows. The overhaul of the audio engine will hopefully be Ok on "test2" for Windows.
But if "the tester" can live with a fragile "Audio back-end" just go ahead. The majority of the new stuff to test is unrelated to audio.
The known bug on "test1" for Windows is that you can't accurately set "block size" and "delay" in audio prefs.
Thank you! Does "not accurately" mean that the values are somewhat off, or that the set values are not respected at all?
going back to your original question:
the patch can still be saved but no longer interacted with graphically using mouse and keyboard. Is such a behavior known?
She should carefully check the patch.
I did, and apart from a busy numberbox following a [metro 5] and a [snapshot~] nothing seems unusual.
Can a patch that triggers the freeze be submitted?
Will mail it to you off-list.
Thank you so much!
best, Peter
On 11/15/2021 6:00 AM, Peter P. wrote:
Does "not accurately" mean that the values are somewhat off, or that the set values are not respected at all?
There's an undefined "integer overflow" in the variable that holds the processed value in the calculations of "delay" with "block-size"
--
- Lucas Cordiviola lucarda27@hotmail.com [2021-11-16 00:04]:
On 11/15/2021 6:00 AM, Peter P. wrote:
Does "not accurately" mean that the values are somewhat off, or that the set values are not respected at all?
There's an undefined "integer overflow" in the variable that holds the processed value in the calculations of "delay" with "block-size"
Thank you! I am still trying to understand how this becomes noticable to the end user (see last question).
Sorry it was a fast and bad answer.
There's a math that puts together: delay * samplerate / blocksize. :
int nbufs = sys_schedadvance * as.a_srate / (blksize *1000000.);
Here "nbuf" gets a negative value (due to integer overflow) for delay 80 blocksize 64. Of course its noticeable because it sounds horrible or "no sound" iirc.
It works fine if:
int nbufs = (double)sys_schedadvance / 1000000. * as.a_srate / blksize;
I can't remember exactly but a delay of 80 is 80000 in sys_schedadvance iirc.
--
Mensaje telepatico asistido por maquinas.
On 11/16/2021 4:46 AM, Peter P. wrote:
- Lucas Cordiviola lucarda27@hotmail.com [2021-11-16 00:04]:
On 11/15/2021 6:00 AM, Peter P. wrote:
Does "not accurately" mean that the values are somewhat off, or that the set values are not respected at all?
There's an undefined "integer overflow" in the variable that holds the processed value in the calculations of "delay" with "block-size"
Thank you! I am still trying to understand how this becomes noticable to the end user (see last question).
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
OK, this should be fixed for the next test release (thanks Dan)
cheers Miller
On Tue, Nov 16, 2021 at 06:51:20AM -0300, Lucas Cordiviola wrote:
Sorry it was a fast and bad answer.
There's a math that puts together: delay * samplerate / blocksize. :
   int nbufs = sys_schedadvance * as.a_srate / (blksize *1000000.);
Here "nbuf" gets a negative value (due to integer overflow) for delay 80 blocksize 64. Of course its noticeable because it sounds horrible or "no sound" iirc.
It works fine if:
   int nbufs = (double)sys_schedadvance / 1000000. * as.a_srate / blksize;
I can't remember exactly but a delay of 80 is 80000 in sys_schedadvance iirc.
--
Mensaje telepatico asistido por maquinas.
On 11/16/2021 4:46 AM, Peter P. wrote:
- Lucas Cordiviola lucarda27@hotmail.com [2021-11-16 00:04]:
On 11/15/2021 6:00 AM, Peter P. wrote:
Does "not accurately" mean that the values are somewhat off, or that the set values are not respected at all?
There's an undefined "integer overflow" in the variable that holds the processed value in the calculations of "delay" with "block-size"
Thank you! I am still trying to understand how this becomes noticable to the end user (see last question).
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.puredata.info_lis...
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.puredata.info_lis...
- Lucas Cordiviola lucarda27@hotmail.com [2021-11-16 10:52]:
Sorry it was a fast and bad answer.
There's a math that puts together: delay * samplerate / blocksize. :
   int nbufs = sys_schedadvance * as.a_srate / (blksize *1000000.);
Here "nbuf" gets a negative value (due to integer overflow) for delay 80 blocksize 64. Of course its noticeable because it sounds horrible or "no sound" iirc.
Thanks Lucas, 80msec was exactly what my colleague is using. We are testing with other values now and will get back to you. Just to get this correct, are all versions before the new "test" version that Miller mentioned affected, so also her 0.51.4? Or only 0.52.0-test1?
best, P
On 11/17/2021 4:39 AM, Peter P. wrote:
affected, so also her 0.51.4? Or only 0.52.0-test1?
0.51-4 is not affected.
Things you could try:
- start Pd from the command line with "pd -noprefs"
- to do this locate the folder (where pd.exe is) on the Windows
file explorer: usually will be on "C:\Program Files\Pd\bin"
- click inside the location bar (on the explorer), and type "cmd"
and press enter.
- this will open a terminal at $(that) location.
- type "pd -noprefs"
- Re-test the patch.
--
Mensaje telepatico asistido por maquinas.
-
Christof Ressi -
Lucas Cordiviola -
Miller Puckette -
Peter P.