Menu

#956 Problem: GUI freezes with Windows OS

closed-fixed
5
2013-01-24
2012-11-06
Anonymous
No

Pd version 0.42.5-extended or 0.43.4-extended 20121101
Windows XP SP3: off the shelves Celeron 2,40Ghz 2Go or VMWare on MacPro OSX Lion (faster, but exactly the same facts)
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 or Linux.
1. on launching, the gui appears more than one minute after the pd console window
2. all gui object are frozen, i.e the GUI objects (sliders, toggles...) do not reflect values received through their receive symbols
3. the turn around to update the window is to miimize it then to maximize it again

Discussion

  • Hans-Christoph Steiner

    yup, I can confirm this, strange... I'll look into it.

     
  • Hans-Christoph Steiner

    • status: open --> pending
     
  • Hans-Christoph Steiner

    It doesn't seem to be the GUI actually. If you look at the Task Manager, or any other process monitor, you can see that it is the 'pd.exe' process that is taking all of the CPU, not the 'wish85.exe' process. 'wish85.exe' is the GUI. For me, 'pd.exe' was using 99% of the CPU while 'wish85.exe' was using 0%.

    Also, while its loading its increasing the amount of RAM, maybe its loading a bunch of arrays?

     
  • Nobody/Anonymous

    Sorry to be so late to answer to you. It loads an array but not so big (1000). The strange thing is that it works fine and fast with Unix based systems (Mac, linux) and not with Windows. Exactly: it works with Windows in the background: the controls sent through the gui objects "send" are passed and executed correctly, but the display of the gui objects is not updated (frozen) when they are used or if they receive updating messages on their "receive" inputs. To defrost, wait for several minutes or unlock by minimizing then maximizing the window.
    If you need to open the patches in the background, you can click on the text "Randolon" in the upper line.
    Some other users encountered that: see http://puredata.hurleur.comviewtopic.php?pid=29719#p29719 (my pseudo is piedagile)
    piedagile@orange.fr

     
  • Hans-Christoph Steiner

    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.

     
  • Nobody/Anonymous

    No non-ASCCII character in that patch.

    I spent some time to make tests. When it is frozen:
    - toggles and bangs are not affected by the problem, but radio, sliders, numbers: yes
    - the edit messages (color, position..) to GUI object are taken in account by the display
    - the problem affects the main window and subpatches

    My own wild guess by testing is that it looks like a jam in the real time: subprocesses launched by abstractions do not complete their jobs in the order they have been sequenced in the pd patch --> some conflicts??
    Example: I initialize the "send" property of a slider, then update its default value by the "receive" property, that makes emitting this number through the "send" property that should be still there . If you do it for a few gui objects, it works, but for several hundreds: jam in Windows (and not at all on a Mac). I do not see how to turn around apart inserting big big delays

    Let me know if I you have idea of other tests I could carry on to contribute...

    Charles

     
  • Nobody/Anonymous

    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.

     
  • Charles Platel

    Charles Platel - 2012-12-03

    "the freezing could be caused by a flow of
    silmutaneous tabread and tabwrite accesses to the same table...."
    It is rather: "the freezing could be caused by a flow of
    silmutaneous tabread and loading a file to the same table"

     
  • Nobody/Anonymous

    After carrying out more in-depth tests:

    I found 2 different causes for freezing (only with Window OS):

    1. trying to load or store with a file path including accents; solution: eliminate accents

    2. trying to update a lot of GUI objects located on a patch which is not the active window: it causes a jam;
    example 1: at the lauch of an app, the abstractions seem lauched before the main patch and can already send messages to the GUI objects of the main patch;
    example 2: with [openpanel] to load a preset text file, just after closing the browser window, pd seems give firstly the control to the abstraction that send the preset values to the GUI objects, before reactiving the window containing them

    The tricky but not sustainable solution: hold the messages from the abstraction until the main patch is "active".

    I made something like this to implement the trick:
    In the main window:

    [active]
    I
    [send $0-active]

    In the abstraction, to hold a bang for instance:

    [inlet] [read $1-active]
    I /I
    I / I ____
    [float ] [spigot 0 ] /
    I I /
    I ______I /
    [!= 1] /
    I--------/
    I
    [outlet]

     
  • Hans-Christoph Steiner

    I fixed issue #1 in the core of Pd-extended, so you can now use unicode characters (accents, umlauts, etc) for filenames and paths. Try it out:

    http://autobuild.puredata.info/auto-build/2012-12-11/

     
  • Charles Platel

    Charles Platel - 2012-12-12

    Both issues seem fixed in this new version.

    - for accented file names in file management pd objects (openpanel, savepanel ....)
    - synchro between father and sons patches at load time. No need for a trick from now on!

    Many thanks HC.

    However, just a remaining thing: when the path to the pd patch itself contains accents, like:
    C:/Documents and Settings/Propriétaire/Bureau/randolon/randolon-95.pd: can't open
    ("Propriétaire" is the default admin account name for the WinXP French version). I created an other account to test the other things, working fine and fast despite a long time for loading.

     
  • Anonymous

    Anonymous - 2013-01-24
    • status: pending --> closed
     
  • Anonymous

    Anonymous - 2013-01-24

    checked as fixed in last 0.43.4

     
  • Hans-Christoph Steiner

    • status: closed --> closed-fixed
     

Anonymous
Anonymous

Add attachments
Cancel