Jonathan Wilkes <[email protected]> wrote:
>I tested the patch from >http://sourceforge.net/tracker/?func=detail&aid=3030159&group_id=55736&atid=478070 >with pd-l2ork (Pd version 0.42.5-extended-l2ork-20110427) >and every time I clicked the tgl in the parent patch it put me into >edit mode. (Doesn't >do that in pd vanilla). Thanks for the report. Allow me to investigate. > >Also, selecting and deselecting the tgl when it has a label gives an >error to the terminal >from which I'm running pd-l2ork: >unknown option "-fill" I have seen this before and I traced it down to tcl/tk. The command is in iemgui objects to allow for global custom colors. The irony is tcltk interprets the flag correctly and online documentation suggests this is a valid flag for the said widget but for some reason it keeps triggering those errors in the console. > >-Jonathan > > >--- On Thu, 7/7/11, Ivica Ico Bukvic <[email protected]> wrote: > >From: Ivica Ico Bukvic <[email protected]> >Subject: Re: [PD] GOP Rendering Issue >To: "Christian Haines" <[email protected]>, >[email protected] >Date: Thursday, July 7, 2011, 8:47 AM > >Neither if those are fixes but rather hacks that should be avoided >because once the bug is fixed you will have to go back and change all >your existing patches with this workaround. Pd already redraws entire >gop object every time you move it or change its properties. I think >this is because of out-of-order redrawing bug that persists in pd (at >least it did since last time I checked). If you can please send a >simplified version of the actual patch to test it in the l2ork >iteration of pd which has afaik all known gop issues fixed, that could >shed some light where the problem lies. > > > >Ivica Ico Bukvic, D.M.A > >Composition, Music Technology > >Director, DISIS Interactive Sound & Intermedia Studio > >Director, L2Ork LinuxLaptop Orchestra > >Assistant Co-Director, CCTAD > >CHCI, CS, and Art (by courtesy) > >Virginia Tech > >Department of Music > >Blacksburg, VA 24061-0240 > >(540) 231-6139 > >(540) 231-5034 (fax) > >disis.music.vt.edu > >l2ork.music.vt.edu > >ico.bukvic.net > >Christian Haines <[email protected]> wrote: >Thanks. I have added a comment to that bug report. >I note somewhere else on the list suggested using a kind of 'whiteout' >approach by moving a white canvas over the the offending items prior to >resizing - after resizing the canvas 'looks' ok. In short, visually >this solves the issue, but if you do this overlapping other objects / >GOPs etc then they suffer from the rendering issue by getting whited >out. >That's part of the workaround. > >To resolve the issue completely (at least visually) I have a receive >object in each GOP abstraction which acts as a global message bus to >all GOPs. This bus is connected to a namecanvas send and sends a vis 0 >and vis 1 message to turn the (and each and every) GOP's visibility >on/off. >There is probably a more elegant solution .. which I'll post when/if I >figure it. >Best >On 06/07/2011, at 12:! > 22 PM, >Hans-Christoph Steiner wrote: > >Hey Christian >Thanks for the thorough bug report, the video is great. I think that's >a known bug, or at least it seems familiar to me. It would be great to >have this info in the bug tracker so we can keep track of it. This bug >seems similar: >https://sourceforge.net/tracker/?func=detail&aid=3030159&group_id=55736&atid=478070 >If that's not it, then feel free to create a new bug report in the >tracker. >.hc >On Jun 28, 2011, at 10:51 PM, Christian Haines wrote: > > >Hi All >I have created an GOP abstraction which I include in a parent parent. >The GOP interface has a button that resizes it by sending a 'coords' >message to the GOP abstraction canvas (namecanvas named). When it >resizes larger it renders the larger interface properly over the >patch's white background. However, when it resizes smaller it leaves a >remnant of the larger interface visible. Sometimes to correctly show >the smaller interface, I have to redraw / refresh the window by moving >the window - this doesn't always work though. In fa! > ct it >only works when the parent patch has a '#coords' line with a specific >configuration in it - of which I'm not sure. I'm on OSX. I've seen the >issue documented elsewhere but never read a full description on how to >resolve it fully. >See the issue here: http://echoblue.com.au/pd/goprenderissue.mov > >At the mo! > ment I >am sending a message back to the parent patch from the GOP abstraction >to change the parent patch's 'setbounds' by 1 pixel and then move it >back - this resolves that issue but, as mentioned, not consistently. >Regardless, it creates two more issues: (1) setbounds behaves oddly - >doesn't resize until a close and reopen; and/or moves the objects in >the patch window without resizing; (2) I can't know the patch window >size dynamically (say by querying the canvas) hence any size change by >setbounds is not necessarily the same as the original window size (if >it was resizing!). >Any suggestions would be greatly appreciated > > >--Christian > >_______________________________________________ >[email protected] mailing list >UNSUBSCRIBE and account-management -> >http://lists.puredata.info/listinfo/pd-list > > > >---------------------------------------------------------------------------- >Terrorism is not an enemy. It cannot be defeated. It's a >tactic. It's about as sensible to say! > we >declare war on night attacks and expect we're going to win that >war. We're not going to win the war on terrorism. - retired >U.S. Army general, William Odom > > > >--Christian Haines >Lecturer / Co-DirectorElectronic Music Unit >Elder Conservatorium of MusicUniversity of AdelaideSouth Australia > 5005 >Ph: +61 8 8303 3799Fax: +61 8 8303 4423Email: >[email protected]: http://emu.adelaide.edu.au > http://music.adelaide.edu.auStudy: >http://emu.adelaide.edu.au/study/Location: Schulz Building, Level 5 , >5.13 > >-----------------------------------------------------------CRICOS >Provider Number >00123M-----------------------------------------------------------This >email message is intended only for the addressee(s) and contains >information that may be confidential and/or copyright. If you are not >the intended recipient please notify the sender by reply email and >immediately delete this email. Use, disclosure or reproduction of this >email by anyone other than the intended recipient(s) is strictly >prohibited. No representation is made that this email or any >attachments are free of viruses. Virus scanning is recommended and is >the responsibility of the recipient. > > > > > > > >-----Inline Attachment Follows----- > >_______________________________________________ >[email protected] mailing list >UNSUBSCRIBE and account-management -> >http://lists.puredata.info/listinfo/pd-list Ivica Ico Bukvic, D.M.A Composition, Music Technology Director, DISIS Interactive Sound & Intermedia Studio Director, L2Ork LinuxLaptop Orchestra Assistant Co-Director, CCTAD CHCI, CS, and Art (by courtesy) Virginia Tech Department of Music Blacksburg, VA 24061-0240 (540) 231-6139 (540) 231-5034 (fax) disis.music.vt.edu l2ork.music.vt.edu ico.bukvic.net _______________________________________________ [email protected] mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
