<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <p>There are canvas_undo_free and canvas_undo_init that may be of
      help.</p>
    <p>Best,</p>
    <p>Ico<br>
    </p>
    <div class="moz-cite-prefix">On 7/30/2020 6:02 PM, Albert Graef
      wrote:<br>
    </div>
    <blockquote type="cite"
cite="mid:CA+rUic3q_iw0f-A5E4kd5LQr6S6kT6k=vy9W7hYUkwm=Ysx3Gw@mail.gmail.com">
      <meta http-equiv="content-type" content="text/html; charset=UTF-8">
      <div dir="ltr">
        <div class="gmail_quote">
          <div dir="ltr" class="gmail_attr">On Thu, Jul 30, 2020 at 9:23
            PM Jonathan Wilkes <<a
              href="mailto:jon.w.wilkes@gmail.com"
              moz-do-not-send="true">jon.w.wilkes@gmail.com</a>>
            wrote:<br>
          </div>
          <blockquote class="gmail_quote" style="margin:0px 0px 0px
            0.8ex;border-left:1px solid
            rgb(204,204,204);padding-left:1ex">Is there already a clear
            method for the undo/redo system?<br>
          </blockquote>
          <div><br>
          </div>
          <div>I don't remember, I haven't looked at that code recently.
            But Ico should be able to answer that question.</div>
          <div> <br>
          </div>
          <blockquote class="gmail_quote" style="margin:0px 0px 0px
            0.8ex;border-left:1px solid
            rgb(204,204,204);padding-left:1ex">
            Also, what is a maintainable way to clear on, say, dynamic
            patching?<br>
          </blockquote>
          <div><br>
          </div>
          <div>Well, dynamic patching happens by sending a bunch of
            special messages representing objects, connections and the
            like to the pd-name receiver, where name is the name of a
            (sub)patch, or a declared canvas name. Clearing the history
            would have to be done in the corresponding patch (or
            canvas?) message handlers. I think that there should be a
            page on dynamic patching with documentation of the available
            messages along with some examples somewhere on <a
              href="http://puredata.info" moz-do-not-send="true">puredata.info</a>.
            A quick search turned up this: <a
              href="http://puredata.info/docs/tutorials/TipsAndTricks#patch-messages"
              moz-do-not-send="true">http://puredata.info/docs/tutorials/TipsAndTricks#patch-messages</a></div>
          <div><br>
          </div>
          <div>Albert<br>
          </div>
          <div> <br>
          </div>
          <blockquote class="gmail_quote" style="margin:0px 0px 0px
            0.8ex;border-left:1px solid
            rgb(204,204,204);padding-left:1ex">
            > On Mon, Jul 27, 2020 at 3:48 AM Jonathan Wilkes <<a
              href="mailto:jon.w.wilkes@gmail.com" target="_blank"
              moz-do-not-send="true">jon.w.wilkes@gmail.com</a>>
            wrote:<br>
            >><br>
            >> Hi all,<br>
            >><br>
            >> It appears that dynamic patching nnd the undo
            system are irreconcilable.<br>
            >><br>
            >> For example-- Suppose you do this:<br>
            >><br>
            >> [namecanvas foo]<br>
            >><br>
            >> [obj 20 20 clip(<br>
            >> |<br>
            >> [send foo]<br>
            >><br>
            >> Whenever you click the message box, a new object
            will be created but<br>
            >> without any undo history.<br>
            >><br>
            >> That's probably desirable behavior, as we don't
            want a bunch of<br>
            >> dynamically created gumming up the undo system.<br>
            >><br>
            >> However, the undo system is based off object
            indices. So by inserting<br>
            >> "[clip]" into a glist we corrupt that system. You
            can see this if<br>
            >> dynamic patching in the middle of other editing
            actions. Doing undo<br>
            >> then redo will put the patch in a corrupt state
            because the indices<br>
            >> will be off by one due to the "[clip]" object that
            the undo system<br>
            >> didn't expect.<br>
            >><br>
            >> I don't know any clean way to deal with this. But
            it affects more than<br>
            >> dynamic patching:<br>
            >><br>
            >> [pointer(<br>
            >> |<br>
            >> [canvasinfo]<br>
            >> |<br>
            >> [20 20 $1(<br>
            >> |<br>
            >> [append some_scalar x y]<br>
            >><br>
            >> Same problem there, as well as:<br>
            >><br>
            >> [pointer(<br>
            >> |<br>
            >> [canvasinfo]<br>
            >> |<br>
            >> [next, delete(<br>
            >> |<br>
            >> [pointer some-scalar]<br>
            >><br>
            >> Each one breaks the assumptions of the undo system
            and undo/redo<br>
            >> actions can have wrong indices.<br>
            >><br>
            >> Even more pressing-- now that we've got pointer
            delete method, the<br>
            >> undo system can have an out-of-bounds index and
            crash when it tries to<br>
            >> deference a null pointer.<br>
            >><br>
            >> Any ideas on how to approach this?<br>
            >><br>
            >> -Jonathan<br>
            >> _______________________________________________<br>
            >> L2Ork-dev mailing list<br>
            >> <a href="mailto:L2Ork-dev@disis.music.vt.edu"
              target="_blank" moz-do-not-send="true">L2Ork-dev@disis.music.vt.edu</a><br>
            >> <a
              href="https://disis.music.vt.edu/listinfo/l2ork-dev"
              rel="noreferrer" target="_blank" moz-do-not-send="true">https://disis.music.vt.edu/listinfo/l2ork-dev</a><br>
            ><br>
            ><br>
            ><br>
            > --<br>
            > Dr. Albert Gr"af<br>
            > Computer Music Research Group, JGU Mainz, Germany<br>
            > Email: <a href="mailto:aggraef@gmail.com"
              target="_blank" moz-do-not-send="true">aggraef@gmail.com</a>,
            web: <a href="https://agraef.github.io/" rel="noreferrer"
              target="_blank" moz-do-not-send="true">https://agraef.github.io/</a><br>
            > _______________________________________________<br>
            > L2Ork-dev mailing list<br>
            > <a href="mailto:L2Ork-dev@disis.music.vt.edu"
              target="_blank" moz-do-not-send="true">L2Ork-dev@disis.music.vt.edu</a><br>
            > <a
              href="https://disis.music.vt.edu/listinfo/l2ork-dev"
              rel="noreferrer" target="_blank" moz-do-not-send="true">https://disis.music.vt.edu/listinfo/l2ork-dev</a><br>
            _______________________________________________<br>
            L2Ork-dev mailing list<br>
            <a href="mailto:L2Ork-dev@disis.music.vt.edu"
              target="_blank" moz-do-not-send="true">L2Ork-dev@disis.music.vt.edu</a><br>
            <a href="https://disis.music.vt.edu/listinfo/l2ork-dev"
              rel="noreferrer" target="_blank" moz-do-not-send="true">https://disis.music.vt.edu/listinfo/l2ork-dev</a></blockquote>
        </div>
        <br clear="all">
        <br>
        -- <br>
        <div dir="ltr" class="gmail_signature">
          <div dir="ltr">
            <div>
              <div dir="ltr">
                <div>
                  <div dir="ltr">Dr. Albert Gr"af<br>
                    Computer Music Research Group, JGU Mainz, Germany<br>
                    Email: <a href="mailto:aggraef@gmail.com"
                      target="_blank" moz-do-not-send="true">aggraef@gmail.com</a>,
                    web: <a href="https://agraef.github.io/"
                      target="_blank" moz-do-not-send="true">https://agraef.github.io/</a></div>
                </div>
              </div>
            </div>
          </div>
        </div>
      </div>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <pre class="moz-quote-pre" wrap="">_______________________________________________
L2Ork-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:L2Ork-dev@disis.music.vt.edu">L2Ork-dev@disis.music.vt.edu</a>
<a class="moz-txt-link-freetext" href="https://disis.music.vt.edu/listinfo/l2ork-dev">https://disis.music.vt.edu/listinfo/l2ork-dev</a></pre>
    </blockquote>
    <pre class="moz-signature" cols="72">-- 
Ivica Ico Bukvic, D.M.A.
Director, Creativity + Innovation
Director, Human Centered Design iPhD
Institute for Creativity, Arts, and Technology

Virginia Tech
Creative Technologies in Music
School of Performing Arts – 0141
Blacksburg, VA 24061
(540) 231-6139
<a class="moz-txt-link-abbreviated" href="mailto:ico@vt.edu">ico@vt.edu</a>

<a class="moz-txt-link-abbreviated" href="http://www.icat.vt.edu">www.icat.vt.edu</a>
<a class="moz-txt-link-abbreviated" href="http://www.performingarts.vt.edu">www.performingarts.vt.edu</a>
l2ork.icat.vt.edu
ico.bukvic.net</pre>
  </body>
</html>