[PD] pd-l2ork feedback

[András Murányi]

On Wed, Feb 27, 2013 at 12:45 AM, Ivica Bukvic <ico at vt.edu> wrote:

> This may be because you didn't hide gop titles, in which case pd-l2ork
> resizes gop size to match the text width.
>
> Yes this is indeed the case. I noticed, however, that there was no title
to be displayed, meaning that with "hide GOP title" unchecked, the
rectangle was bigger but there was no title (see attachment).
And it shows the frame when it's embedded in another GOP.

> Regarding slow redraw, can you try latest version? I fixed one major
> inefficiency.
>
I'll try it as soon as I get to it. I noticed meanwhile that during the
hangup, this error is thrown to the command line a few times:
tcl/tk error: unknown encoding "yahoo"

András



> On Feb 26, 2013 6:22 PM, "András Murányi" <muranyia at gmail.com> wrote:
>
>> Thanks for the reply.
>> The hangup is literally 5 minutes, CPU is maxed out most of the time. The
>> undo takes 5 seconds, again literally.
>> It doesn't occur in pd-extended.
>>
>> Nested gop subpatches should show their outlines and xlets (just like
>>> number2 or toggle does as well), shouldn’t they?
>>>
>>
>> Well, traditionally they don't and I think they should not. This would be
>> consistent behavior if the borders of every element in the outer GOP
>> subpatch would be visible. *However, I was wrong and actually this is not
>> what's happening.*
>> Rather, it seems that some GOP subpatches have the wrong size, and then
>> they also show thru nested GOPs. See the attached screenshot: at the top
>> left corder of the open subpatch, there are two GOP subpatches ("Cut" and
>> "Res"; their guts are shown in the open subpatch window), each wider than
>> they should be. The big gray rectangle at the bottom of the image is a
>> large GOP subpatch itself, and the same nested GOP shows thru it. I
>> couldn't reproduce this symptom from scratch.
>>
>> András
>>
>>
>> On Fri, Feb 22, 2013 at 10:37 PM, Ivica Ico Bukvic <ico at vt.edu> wrote:
>>
>>>  One clarification now that I read your report more carefully. Mknob
>>> makes abstraction movement slower because this is the old/non-accelerated
>>> pd way of moving things. The new pd-l2ork model falls back on that when at
>>> least one object in the abstraction does not support accelerated moving.
>>> Once I get to fixing the mknob to support accelerated displace, this will
>>> be fixed. I am still surprised to hear this is taking 5 minutes, though. Is
>>> this an exaggeration or truly 5 minutes?
>>>
>>> Also, if you are undoing objects that are non-accelerated or complex
>>> abstractions, you are running into same problems because you are moving and
>>> redrawing non-accelerated way...
>>>
>>> Is the same slowness perceived on regular pd when moving the said
>>> abstraction?
>>>
>>>
>>
>>>
>>> On 02/22/2013 03:34 PM, András Murányi wrote:
>>>
>>> So, I've played around with the last git, here are some things I've
>>> noticed:
>>> - miXed/toxy is not in pd-l2ork and it's perfectly alrite because some
>>> kinds of [widget] work while others not.
>>> - [flatgui/popup] is installed by default but it throws an error when
>>> clicked on: Invalid command name "pdtk_canvas_mouse".
>>> - moving a simple GOP abstraction with a single [mknob] in it takes like
>>> 5 minutes (!) on a 2.4GHz dual core when the patch is big. It's fast
>>> however when the patch is simple. Undoing the movement is not instant but
>>> it is quick (~5sec).
>>> - nested GOP subpatches show off their outlines and xlets.
>>>
>>> --
>>> Murányi András
>>>
>>>
>>
>> _______________________________________________
>> Pd-list at iem.at mailing list
>> UNSUBSCRIBE and account-management ->
>> http://lists.puredata.info/listinfo/pd-list
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20130227/b5851f1b/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Screenshot.png
Type: image/png
Size: 25426 bytes
Desc: not available
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20130227/b5851f1b/attachment-0001.png>