<html>
  <head>
    <meta content="text/html; charset=windows-1252"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    Hi Ico,<br>
    <br>
    Indeed pd-extended is able to recognize an external object that is
    inside a subfolder of a path when the subfolder has the same name. I
    find feature useful to organize objects, because you keep them,
    their help files and any other files such as readme that may come
    with them. It also makes it slightly faster to add new objects,
    since no modification to the path is necessary. If it is a feature
    or byproduct, I really wouldn't know.<br>
    <br>
    But indeed this is not an important issue at all, I just wanted to
    bring it to light because of the difference of behaviour when
    compared with pd-extended rather than asking for the feature to be
    implemented.<br>
    <br>
    Best,<br>
    Gilberto<br>
    <br>
    <div class="moz-cite-prefix">On 15/11/14 04:54, Ivica Ico Bukvic
      wrote:<br>
    </div>
    <blockquote cite="mid:5466CE67.6040906@vt.edu" type="cite">
      <meta content="text/html; charset=windows-1252"
        http-equiv="Content-Type">
      I think this is something I don't feel as strongly about as you
      do. Perhaps one possibility would be to recursively navigate
      subfolders, rather than devising some kind of a one-of navigation
      with a subfolder. But there is a more fundamental problem we need
      to tackle first which is the order of paths in respect to
      individual patches. I agree with Jonathan that the first place a
      patch should look is its own folder and then go from there to
      explore the rest of the paths. If so, I would first worry about
      this, then worry about recursive searching of an object, which
      would also address your request.<br>
      <br>
      All that said, I am wondering if you are suggesting that
      pd-extended is able to recognize an external in a subfolder with a
      same name? If so, I wonder if this is a feature or a byproduct of
      the current implementation...<br>
      <br>
      Best,<br>
      <br>
      Ico<br>
      <br>
      <div class="moz-cite-prefix">On 11/14/2014 7:54 PM, Gilberto
        Agostinho wrote:<br>
      </div>
      <blockquote cite="mid:5466A43A.2070502@gmail.com" type="cite">
        <meta content="text/html; charset=windows-1252"
          http-equiv="Content-Type">
        <link href="chrome://translator/skin/floatingPanel.css"
          type="text/css" rel="stylesheet">
        Hi all,<br>
        <br>
        I am sorry to bump this up, but I have the impression this
        message got forgotten in the middle the discussions about the
        latest commits.<br>
        <br>
        Best,<br>
        Gilberto<br>
        <br>
        <div class="moz-cite-prefix">On 13/11/14 03:34, Gilberto
          Agostinho wrote:<br>
        </div>
        <blockquote cite="mid:546418B7.4070200@gmail.com" type="cite">Hello


          all, <br>
          <br>
          I just found out that Pd-l2Ork behaves differently than
          Pd-extended when it comes to the path of external objects.
          Let's say I have some objects named exampleN and their help
          files in the following folder structure: <br>
          <br>
          ~/.pd/extra-objects/example1/example1.pd <br>
          ~/.pd/extra-objects/example1/example1-help.pd <br>
          ~/.pd/extra-objects/example2/example2.pd <br>
          ~/.pd/extra-objects/example2/example2-help.pd <br>
          ~/.pd/extra-objects/example3/example3.pd <br>
          ~/.pd/extra-objects/example3/example3-help.pd <br>
          <br>
          That is, I don't want to simply put all these extra objects in
          a same folder, each one has their one specific folder with the
          same name. With Pd-extended, I could simply add
          ~/.pd/extra-objects to my path, and all of them would be
          automatically loaded (if and only if their subfolder names are
          the exact same as the object's name). This is very handy
          because you can organize your objects better, and also needs
          less work than adding each single one of them to your path. <br>
          <br>
          What do you think about this? <br>
          <br>
          Best, <br>
          Gilberto <br>
        </blockquote>
        <br>
        <div style="bottom: auto; left: 755px; right: auto; top: 54px;
          display: none;" class="translator-theme-default"
          id="translator-floating-panel"> </div>
        <br>
        <fieldset class="mimeAttachmentHeader"></fieldset>
        <br>
        <pre wrap="">_______________________________________________
L2Ork-dev mailing list
<a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:L2Ork-dev@disis.music.vt.edu">L2Ork-dev@disis.music.vt.edu</a>
<a moz-do-not-send="true" class="moz-txt-link-freetext" href="http://disis.music.vt.edu/listinfo/l2ork-dev">http://disis.music.vt.edu/listinfo/l2ork-dev</a></pre>
      </blockquote>
      <br>
      <pre class="moz-signature" cols="72">-- 
Ivica Ico Bukvic, D.M.A.
Associate Professor
Computer Music
ICAT Senior Fellow
DISIS, L2Ork
Virginia Tech
School of Performing Arts – 0141
Blacksburg, VA 24061
(540) 231-6139
<a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:ico@vt.edu">ico@vt.edu</a>
<a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="http://www.performingarts.vt.edu">www.performingarts.vt.edu</a>
disis.music.vt.edu
l2ork.music.vt.edu</pre>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br>
      <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="http://disis.music.vt.edu/listinfo/l2ork-dev">http://disis.music.vt.edu/listinfo/l2ork-dev</a></pre>
    </blockquote>
    <br>
  </body>
</html>