<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <div class="moz-cite-prefix">On 06/14/2013 12:07 PM, Jonathan Wilkes
      wrote:<br>
    </div>
    <blockquote
      cite="mid:1371226060.91316.YahooMailNeo@web160302.mail.bf1.yahoo.com"
      type="cite">
      <div style="color:#000; background-color:#fff; font-family:arial,
        helvetica, sans-serif;font-size:12pt"><br>
        <div style="font-family: arial, helvetica, sans-serif;
          font-size: 12pt;">
          <div style="font-family: times new roman, new york, times,
            serif; font-size: 12pt;">
            <div class="y_msg_container">&gt;The real problem is: having
              the feature forces every pd flavor to<br>
              &gt;understand them at the file format level, even if not
              rendering it.<br>
              <br>
              If the "connect" method took A_GIMME you could just follow
              its<br>
              initial four floats with a list of coordinates.<br>
              <br>
              -Jonathan<br>
            </div>
          </div>
        </div>
      </div>
    </blockquote>
    Indeed. This is how pd-l2ork maintains backwards compatibility for a
    number of features. That said, storing coordinates in the existing
    file format and/or drawing the cord are not the problem. The problem
    is what happens when you translate the object the cord is connected
    to? Uncovering logic whether all the coordinates need to be
    translated (as opposed to only last one) is something that even Max
    fails to do gracefully despite the fact it has been capable of this
    for over 10 years, perhaps in part because there is no
    perfect/graceful way to deal with this that does not require some
    fairly evolved logic.<br>
    <br>
    Another challenge is cord selection. What needs to be checked is if
    the existing cord selection logic is indeed robust to handle new
    segmented cords. Although my memory is not what it used to be, as
    far as I remember, the hitbox detection is fairly primitive when it
    comes to cords and in its current form is not capable of gracefully
    handling this. Please correct me if I am wrong.<br>
    <br>
    Perhaps more pressing matter IMO is ability to multiselect cords so
    that you can erase many of them at once without having to resort to
    hack-ish ways of cutting and pasting objects.<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>