Hi, sometimes the number boxes and sliders appear to be "frozen". Even though the slider doesn't seem to move and the number box doesn't show any difference when interacting with it, there is an audible difference. Anyone who knows what might cause this problem? I'm using windows 7

same problem here. I remember having encoutered this before in patches with a lot of GUI going on, but now I am also seemingly encountering it in patches with less GUI. And i've tried both 42.5 and 41.4 versions of PD. Could it be a windows issue? It's strange that this bug suddenly should hit so with full force, I can't even open certain patches without the GUI freezing at once. Sound and values of the GUI still work, I just can't see them.

Read another post here on the forum with the same issue, but not any solutions there either to fix it. Halp!

OK! So, I set PD to run in compabilitymode with XP service pack 3, and so far (5 minutes running into the patch) it seems like everything is working again! YAY! Hope it works for you too, and that it continues to work for me.

OK! Back to eat my words. Was working for a while, suddenly, GUI locked up again... *sigh* It happened when I copied another object full of GUI (with random variables like $0-stuff). No idea.... I also saw an error about an outdated [pow~] object, so I guess I'll change that and see if it helps.. hmm...

got this today, and a few times recently. I was copying some stuff form the help file patches around the same time, although it could be unrelated. Mac osx here...

I think I have made an observation. This only seems to happen when I load samples from my external harddrive. Is this also the case with the rest of you?

It happens to me sometime when a load a .pd file from the desktop...

Hello all
I try to create a windows version of a big MIDI app with many gui objects and abstractions, that runs perfectly and with few latencies on OSX.
1. on Windows launching, the gui appears more than one minute after the pd console
2. all gui object are frozen, but operate, as described by Rlilvt; a turn around was to wait for loading completed, then manually bang the application initialization loadbang; after, it works, not frozen, with very few CPU load
3. trying to load an external "preset" file to initiate gui objects from values stored in a table, it freezes again. Maybe pd can't synchronize the asynchronous tabwrite/tabread flow?

Configuration: OSX: macPro, macbook Pro
Windows XP SP3: off the shelves Celeron 2,40Ghz 2Go, or VMWare on MacPro (faster, but exactly the same facts)

I've got exactly the same problem on vista, whereas everything works great on osx tiger.

I've noticed that if you minimize the window and maximize it your values will be updated in the gui but it doesn't fix the pb...

@BerengerRecoules said:

I've got exactly the same problem on vista, whereas everything works great on osx tiger.

I've noticed that if you minimize the window and maximize it your values will be updated in the gui but it doesn't fix the pb...

Hi Berenger
You have found a magic turn-around for this problem: it works!
Now when I use a PC, everytime I move a slider I minimize the window, then have a drink, then maximize, and so on. Now: perfectly happy!

Seriously, your remark should be useful to find where is the bug.

Hi, same problem here on windows 7.
Slides froze after using the [openpanel] and loading a .wav to [soundfiler].

I was trying to run my patch on windows xp when I figured out that the problem occur only when the filename of the .wav contains an accent. Removed all accents from the file and now all the slides work!

Hope it will work for the others.

any solution to this yet guys. im running mac OSx snow leopard and mine goes as far as crashing. minimizing trick works and i also found is you print all your data it doesnt actually crash so that helps a little.

@piedagile said:

Hello all
I try to create a windows version of a big MIDI app with many gui objects and abstractions, that runs perfectly and with few latencies on OSX.
1. on Windows launching, the gui appears more than one minute after the pd console
2. all gui object are frozen, but operate, as described by Rlilvt; a turn around was to wait for loading completed, then manually bang the application initialization loadbang; after, it works, not frozen, with very few CPU load
3. trying to load an external "preset" file to initiate gui objects from values stored in a table, it freezes again. Maybe pd can't synchronize the asynchronous tabwrite/tabread flow?

Configuration: OSX: macPro, macbook Pro
Windows XP SP3: off the shelves Celeron 2,40Ghz 2Go, or VMWare on MacPro (faster, but exactly the same facts)

New test:
I tried the same with the new Pd-extended 0.43.4 beta on XP. Although launching is much more fast than before, gui objects stay frozen and can be updated only by minimizing then maximizing the window.

Sounds to me like this problem is related to non-ASCII characters, like any character with an accent, umlaut, etc. Can anyone confirm that this happens when a patch has only ASCII characters?

I am upgrading the embedded Tcl/Tkto 8.5.13 in the Windows build right now in the hopes that it might fix this. My wild guess is that its related to unicode.

I found a trick to avoid freezing the GUI window:
I simply replaced the [loadbang] of the starting program by [active]___[sel
1]____[once] placed in the GUI window, which is the father of all
subpaches.
So every abstraction is really ready to work at start. I made the change in
the Mac version also, although there was no freezing.
But it is a trick and I think it is not a sustainable solution for other
people.
During my tests I found that the freezing could be caused by a flow of
silmutaneous tabread and tabwrite accesses to the same table.

I have the same problem with ubuntu studio 12.04

My patch has only ASCII characters

Thanx

Thanks to Hans, it is now fixed by pd-extended 0.43.4 on Windows system.

Hi everyone! I am just having difficulties doing that tcl/tk update in OSX, that suppose to fix that GUI freezing nightmare Could somebody give me some instructions, it would help a lot. Thanks in adv.

Ive got a similar problem running OS X High Sierra and Purr Data 2.3.3. Patches seem frozen, but audible response moving sliders. Certain objects in my patch does not work at all though...like "Key" for instance...although when I add the "Key" object next to the patch it does work...
Im confused.
In fact PD Extended doesn't work AT ALL. And PD vanilla 0.48 just stopped working as well.

PD just isn't working for me. I hope somebody has some solution to this as Im not really keen to migrate to Max.

Thanx for any clarity on this!

@minothi afaik when Pd is under heavy load, it stops updating the GUI objects, although they still work. This is to protect the audio generation.

Possible workarounds:

• Reduce GUI objects, put unneeded GUI objects/ graphical arrays in subpatches
• Reduce complexity of your code/optimize patch: This would help so Pd isn't going under heavy load in the first place
• Maybe try Purr Data instead

@minothi If all of your patches are frozen then it is likely to be your audio settings.
Did you change your Pd "audio settings" recently?
If audio is struggling it will badly affect re-drawing of the GUI.
All OS give audio "priority"...... over windowing and video.
Is it possible that all your Pd installations look to the same "prefs" file? I don't know.
If you cannot change the audio settings..... the window will not respond, or it crashes Pd, make a note of the settings and then open this patch....... Pd Fix.zip
But read the "readme" first.
David.