graphics in GUI Objects freeze completely (tested ubuntu 17.04, 16.04 and OSX el-capitan
some patches that are loaded will glitch something out, causing all GUI objects to graphically freeze while still sending their values and otherwise functioning normally. Once the glitch occurs, the problem will remain in every patch window, even if you start a new patch. Structs, images and message boxes seem unaffected. Changes to the objects label shows up fine, but the display of the value in the objects core function, such as the numbers of [nbx], line in [hslider], highlighted square of [hradio] etc. will not update their values until a window is redrawn or resized. In effect, the objects have an appearance of being completely frozen, but their values are still being sent and received.
The glitch seems more likely to happen in larger patches with more complex use of GOP subpatches and overlapping of elements, though I have seen it occur in smaller patches in some cases.
My intuition tells me it is somehow related to [ggee/image] objects, as when the bug is active, I see this message a lot in the console: "legacy tcl command at 447 of gui/image.c: image delete imgdf123d10"
I have found the problem to be present in multiple versions of Ubuntu as well as OSX. While I couldn't seem to recreate it by building a new patch, I found a relatively small patch which was built using purr-data 2.2.3 in OSX that consistently causes the bug to occur without being too huge and complex. It's also a handy network receiver object designed to easily receive midi notes from other patches over the network. This patcher works perfectly in older pd-l2ork v1.xx, but consistently causes the bug in question in every version of Purr-data That I tested. The main patcher file contained is named CM-network.pd Cheersnetwork-notein.zip
Activity
Can't reproduce on Purr Data 2.2.4 running on Windows.
Did you try the 2.2.4 binary?
https://github.com/jonwwilkes/purr-data/releases
Edit: using the github release page instead of the gitlab one that I'm getting rid of soon
Edited by Jonathan Wilkes
Confirmed. bug persists in the latest binary in ubuntu studio 17.04 and 16.04. If you are using windows and it is not occuring, then perhaps it is related to unix operating systems? I have tried it on multiple versions in multiple distros on multiple different machines... Even in OSX, and it is there in every one. The fact that every setup that I attempt to test it on shows the same behavior makes me puzzled that no one else seems to be experiencing this, or at least has not mentioned it anywhere I could find it. Is there something else I can do to help track this down? I am happy and even a bit eager to be involved in helping this project in any way that I can.
Edited by th8a-
Sure. Well, for start, I probably should have mentioned that the number boxes which you see in the patch there appear to work normally because I used a work around to compensate for the glitch while building it, as I didn't originally build that as a debugging patch but as part of a bigger project... so if you look closely, you will see that the number boxes are actually GOP sub patches. In the subpatch, the number box is feeding it's value into a send object that sets the label of the box to its value,and its normal display area is set to the same color as the background to give it the appearance that it works normally. If you create a new nbx or gui object anywhere in that patch, however, the bug will be seen (assuming it is present in Windows versions.) Also in my testing, if you open any patch that causes the glitch to occur, then close it and open a new patch, the glitch will persist until you restart the whole program. The error message output message from the console that I mentioned above seems to happen when interacting with [ggee/image], which were used in the patch I posted as light indicators and fancy toggle switches. Those objects otherwise work fine, save some occasional graphics clipping and sporadic movements when switching images. Please let me know if you have more questions and rather or not you are able to spot the glitch. Cheers
The bug happens because I took a synchronous GUI command interpreter that ignores non-existent items and ported it to an asychronous GUI command interpreter that doesn't ignore non-existent items without totally understanding the consequences.
Your "loadbang" message inside the ggee/image abstractions ends up sending a message to update the image before Pd has actually drawn the image. Pd Vanilla works that way, too, but tcl/tk just ignores the command if the item doesn't exist. For the ggee/image GUI code, I'm not yet protecting against such messages. Doing so should fix the bug.
There are a few fairly straightforward ways to refactor pdgui.js code to handle this in a general way, but for the time being I'm just doing it manually.
-
Oh wow! Just put it to the test and answered my own question! The patch is fixed! You're a sharp dude. Thanks a million! This bug has been a thorn in my ass for months! It's the one reason I have been hanging back in older versions of pd-l2ork to run all of my older patches. Now I can keep with the times and enjoy the upgraded pd. I'm super stoked. Please let me know if there's anything I can do to help the project. If you need beta testers, UI designs, help patch creators - whatever I can do to contribute, I'd be honored. Cheers!
-
Hey, man. So a little update here... In a much larger and complex patch that I am reworking for purr-data, I went through and changed every loadbang to a receive object that gets one master loadbang which I can control with a delay. I set a real long delay and when the window opened, the number boxes and everything were working! Then, the loadbang went off and it all froze. There is definitely something going on with ggee/image, but I think it's beyond just the loadtime of the gui. I am guessing this bug also pertains to pmenu, opendialogue, etc. as those will all put out similar messages to the console and exhibit similar behavior. Just thought Id mention it to you.
\"console output: ../shared/hammer/file.c: hammereditor_close .e6f32f40 0 [2] legacy tcl command at 112 of gui/image.c: catch {image delete $imge86aca40} legacy tcl command at 447 of gui/image.c: image delete imge86aca40 [2] legacy tcl command at 112 of gui/image.c: catch {image delete $imge86b4b20} legacy tcl command at 447 of gui/image.c: image delete imge86b4b20 legacy tcl command at 112 of gui/image.c: catch {image delete $imge874b4b0} legacy tcl command at 447 of gui/image.c: image delete imge874b4b0 error: audio I/O dropout error: #5629e812f710: no such object [114] error: x5629e736ef60: no such object\"Edited by th8a -
yea, I like dropdown. It was a much needed object in pd. Having first learned msp in Max, I admit that I am a bit spoiled when it comes to UI aesthetics...
If I wanted to learn the ropes of this project's style of development, could you maybe point me to some study material? I am self taught in msp, C and beginning java.. and as the quest for knowledge continues, the stuff i'd need to know to be of real use around here would be my next chosen phase of study.
-
"opendialogue"?
oops sorry, there goes my old Max msp habits as we speak. I meant savepanel and loadpanel.
Edited by th8a If I wanted to learn the ropes of this project's style of development, could you maybe point me to some study material?
A lot of it is listed on the main project page:
https://git.purrdata.net/jwilkes/purr-data
You can also join up on the dev list and tell us what kind of stuff you'd like to work on:
http://disis.music.vt.edu/cgi-bin/mailman/listinfo/l2ork-dev
-
hey again. I have been doing my best to further track down the problem. I am getting familiar with the dev tools and debug modes etc... I have a pretty hot lead on the problem, but of course I am untangling a ginormous patch to figure out where it's occuring. I have my own preset node recall system which I designed around [cyclone/coll] from the ol' max days that works really well my purposes. Now, the gui works when the patch launches, but recalling a preset is triggering the freeze. At first I thought it had maybe something to do with the coll object, as I know it is not fully yet implemented in purr, but then I narrowed it down further still and figured out that what is happening is that when a preset is recalled, it spits out a bunch of values to a bunch of different ui objects, including ggee/image objects. Anyway... what seems to be happening is that somewhere in the transfer of data between js and the gui, it's unable to keep up with all of the change and drops the connection to the UI, as is made evident by this console output that shows up every time it happens:
`gui_ping /opt/purr-data/lib/pd-l2ork/bin/pdgui.js:1734 return patchwin[cid].window.document.getElementById(object + "gobj"); ^
TypeError: Cannot read property 'window' of undefined at get_gobj (/opt/purr-data/lib/pd-l2ork/bin/pdgui.js:1734:25) at gui_gobj_erase (/opt/purr-data/lib/pd-l2ork/bin/pdgui.js:2299:13) at eval (eval at perfect_parser (/opt/purr-data/lib/pd-l2ork/bin/pdgui.js:1662:21), :1:1) at perfect_parser (/opt/purr-data/lib/pd-l2ork/bin/pdgui.js:1662:21) at Socket. (/opt/purr-data/lib/pd-l2ork/bin/pdgui.js:1680:9) at emitOne (events.js:96:13) at Socket.emit (events.js:191:7) at readableAddChunk (_stream_readable.js:178:18) at Socket.Readable.push (_stream_readable.js:136:10) at TCP.onread (net.js:560:20) `
Anyway, just staying vigilant here and doing my thing... hope that is somehow helpful. Cheers.
UPDATE: I found it! It's not ggee/image at all! It'a the graphical arrays that are triggering it! This patch makes use of multiple arrays in something like an editing grid for a step sequencer. Just a little click and drag of some array objects and whamo - our bug emerges. I am making use of the [r array-name_changed] to trigger [tab-dump] to spit out a lot of stuff... maybe that has something to do with it?
Edited by th8a TypeError: Cannot read property 'window' of undefined at get_gobj (/opt/purr-data/lib/pd-l2ork/bin/pdgui.js:1734:25) at gui_gobj_erase
That's a strange error to get from a preset recalling data. Are you quickly opening and closing a window or something like that? Anyway, it's very possible this is related to the previous error I discussed above. The workaround I gave you is for problems at load time. But if the patch is complex enough that workaround won't be effective.-
it's very possible this is related to the previous error I discussed above.
Yes, well I am sure it is related. By applying your workaround I was able to greatly improve the situation, only to find that there's more to it still. One thing was an invisible [menubutton] that I failed to delete from the previous version, hiding like a ninja and confusing the eb and signal flow.
I don't think that it is the recalling of the presets that directly causes it, but the onslaught of UI elements which must be redrawn all at once to ensue immediately thereafter. As far as I am aware, there are no windows opening or closing. There are however, images loading, number boxes, sliders, toggles etc changing, arrays being pushed and pulled... The patch is about the size and graphical complexity that you would expect from a fairly meaty and modern VST plugin or something like it. It's a complex patch, but nothing beyond what a quad-core i7 and newer NVIDIA gpu wouldn't be able to handle while napping... And I use this patch every day in the studio with no problems in it's older form on pd-l2ork. It would seem there is a bottleneck somewhere. I'll stay on it and post anything of significance that i may find... Im gonna hunt this bug like will smith in that MiB movie. lol.
Edited by th8a mentioned in commit 37a08928
mentioned in merge request !117 (merged)
closed via commit 37a08928
