<html>
  <head>
    <meta content="text/html; charset=windows-1252"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <div class="moz-cite-prefix">On 02/26/2013 09:07 PM, András Murányi
      wrote:<br>
    </div>
    <blockquote
cite="mid:CAJtGUK6uAY+jS+GzYRpmT6xfZfr2MTnThHh4TXet3w2VGc_BHg@mail.gmail.com"
      type="cite">
      <div class="gmail_quote">On Wed, Feb 27, 2013 at 12:45 AM, Ivica
        Bukvic <span dir="ltr">&lt;<a moz-do-not-send="true"
            href="mailto:ico@vt.edu" target="_blank">ico@vt.edu</a>&gt;</span>
        wrote:<br>
        <blockquote class="gmail_quote" style="margin:0 0 0
          .8ex;border-left:1px #ccc solid;padding-left:1ex">
          <p dir="ltr">This may be because you didn't hide gop titles,
            in which case pd-l2ork resizes gop size to match the text
            width.</p>
        </blockquote>
        <div>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).<br>
          And it shows the frame when it's embedded in another GOP. <br>
        </div>
      </div>
    </blockquote>
    <br>
    AFAIK embedded GOP objects have always had frames. This is why all
    iemguis also have frames/inlets/outlets even when embedded inside
    GOP. I think your background made them hard to distinguish. I could
    be wrong, though, but I always remember seeing those.<br>
    <br>
    As for the text not being displayed, can you send me the slider
    abstraction? It could be that since you've originally saved the
    abstraction inside regular pd that it did not get adjusted
    completely to conform to pd-l2ork's way of dealing with these. Try
    manually readjusting the GOP size and re-save it. It should either
    prevent you from resizing it below the text size or do it just fine
    provided you've disabled the showing of text. As for text not
    showing in a subpatcher even though it should, this is something I
    should investigate.<br>
    <blockquote
cite="mid:CAJtGUK6uAY+jS+GzYRpmT6xfZfr2MTnThHh4TXet3w2VGc_BHg@mail.gmail.com"
      type="cite">
      <div class="gmail_quote">
        <blockquote class="gmail_quote" style="margin:0 0 0
          .8ex;border-left:1px #ccc solid;padding-left:1ex">
          <p dir="ltr">Regarding slow redraw, can you try latest
            version? I fixed one major inefficiency.</p>
        </blockquote>
        <div>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:<br>
          tcl/tk error: unknown encoding "yahoo"<br>
        </div>
      </div>
    </blockquote>
    This likely refers to text encoding if you use something
    unusual/setup-specific.<br>
    <br>
    HTH<br>
    <blockquote
cite="mid:CAJtGUK6uAY+jS+GzYRpmT6xfZfr2MTnThHh4TXet3w2VGc_BHg@mail.gmail.com"
      type="cite">
      <div class="gmail_quote">
        <div><br>
          András<br>
          <br>
           </div>
        <blockquote class="gmail_quote" style="margin:0 0 0
          .8ex;border-left:1px #ccc solid;padding-left:1ex">
          <div class="gmail_quote">
            <div>
              <div class="h5">On Feb 26, 2013 6:22 PM, "András Murányi"
                &lt;<a moz-do-not-send="true"
                  href="mailto:muranyia@gmail.com" target="_blank">muranyia@gmail.com</a>&gt;
                wrote:<br type="attribution">
              </div>
            </div>
            <blockquote class="gmail_quote" style="margin:0 0 0
              .8ex;border-left:1px #ccc solid;padding-left:1ex">
              <div>
                <div class="h5">
                  Thanks for the reply.<br>
                  The hangup is literally 5 minutes, CPU is maxed out
                  most of the time. The undo takes 5 seconds, again
                  literally.<br>
                  It doesn't occur in pd-extended.<br>
                  <br>
                  <blockquote style="margin:0px 0px 0px
                    0.8ex;border-left:1px solid
                    rgb(204,204,204);padding-left:1ex"
                    class="gmail_quote">
                    Nested gop subpatches should show their outlines and
                    xlets (just like number2 or toggle does as well),
                    shouldn’t they?<br>
                  </blockquote>
                  <div><br>
                    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.*<br>
                  </div>
                  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.<br>
                  <br>
                  András<br>
                  <br>
                  <br>
                  <div class="gmail_quote">On Fri, Feb 22, 2013 at 10:37
                    PM, Ivica Ico Bukvic <span dir="ltr">&lt;<a
                        moz-do-not-send="true" href="mailto:ico@vt.edu"
                        target="_blank">ico@vt.edu</a>&gt;</span> wrote:<br>
                    <blockquote class="gmail_quote" style="margin:0 0 0
                      .8ex;border-left:1px #ccc solid;padding-left:1ex">
                      <div bgcolor="#FFFFFF" text="#000000">
                        <div>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?<br>
                          <br>
                          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...<br>
                          <br>
                          Is the same slowness perceived on regular pd
                          when moving the said abstraction?<br>
                           </div>
                      </div>
                    </blockquote>
                    <blockquote class="gmail_quote" style="margin:0 0 0
                      .8ex;border-left:1px #ccc solid;padding-left:1ex">
                      <div bgcolor="#FFFFFF" text="#000000">
                        <div>
                          <div>
                            <div><br>
                              <br>
                              On 02/22/2013 03:34 PM, András Murányi
                              wrote:<br>
                            </div>
                          </div>
                        </div>
                        <blockquote type="cite">
                          <div>
                            <div>So, I've played around with the last
                              git, here are some things I've noticed:<br>
                              - miXed/toxy is not in pd-l2ork and it's
                              perfectly alrite because some kinds of
                              [widget] work while others not.<br>
                              - [flatgui/popup] is installed by default
                              but it throws an error when clicked on:
                              Invalid command name "pdtk_canvas_mouse".<br>
                              - 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).<br>
                              - nested GOP subpatches show off their
                              outlines and xlets.<br clear="all">
                              <br>
                              -- <br>
                              Murányi András <br>
                            </div>
                          </div>
                        </blockquote>
                      </div>
                    </blockquote>
                  </div>
                  <br>
                  <br>
                </div>
              </div>
              <div class="im">_______________________________________________<br>
                <a moz-do-not-send="true" href="mailto:Pd-list@iem.at"
                  target="_blank">Pd-list@iem.at</a> mailing list<br>
                UNSUBSCRIBE and account-management -&gt; <a
                  moz-do-not-send="true"
                  href="http://lists.puredata.info/listinfo/pd-list"
                  target="_blank">http://lists.puredata.info/listinfo/pd-list</a><br>
                <br>
              </div>
            </blockquote>
          </div>
        </blockquote>
      </div>
      <br>
      <br>
    </blockquote>
    <br>
    <br>
    <pre class="moz-signature" cols="72">-- 
Ivica Ico Bukvic, D.M.A
Composition, Music Technology
Director, DISIS Interactive Sound &amp; Intermedia Studio
Director, L2Ork Linux Laptop Orchestra
Head, ICAT IMPACT Studio
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</pre>
  </body>
</html>