<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <p>Hello,<br>
    </p>
    <div class="moz-cite-prefix">On 26/03/2021 19:14, Jonathan Wilkes
      wrote:<br>
    </div>
    <blockquote type="cite"
cite="mid:CAOA7yC59prpFDK15dLOPUQatStUAaFzd=-_yZJ21qycYENzeqw@mail.gmail.com">
      <meta http-equiv="content-type" content="text/html; charset=UTF-8">
      <div dir="ltr">
        <div dir="ltr">On Fri, Mar 26, 2021 at 12:42 PM Gabriela
          Bittencourt <<a
            href="mailto:gabrielabittencourt00@gmail.com"
            moz-do-not-send="true">gabrielabittencourt00@gmail.com</a>>
          wrote:<br>
        </div>
        <div class="gmail_quote">
          <blockquote class="gmail_quote" style="margin:0px 0px 0px
            0.8ex;border-left:1px solid
            rgb(204,204,204);padding-left:1ex">
            <div>
              <p>I don't know if the image I sent in the last e-mail
                could be seen, if it could, please ignore this e-mail</p>
              <div>On 26/03/2021 17:27, Gabriela Bittencourt wrote:<br>
              </div>
              <blockquote type="cite">On 26/03/2021 15:04, Jonathan
                Wilkes wrote: <br>
                <br>
                <blockquote type="cite">On Fri, Mar 26, 2021 at 5:36 AM
                  Gabriela Bittencourt <br>
                  <a href="mailto:gabrielabittencourt00@gmail.com"
                    target="_blank" moz-do-not-send="true"><gabrielabittencourt00@gmail.com></a>
                  wrote: <br>
                  <blockquote type="cite">Hello everyone, <br>
                    <br>
                    My name is Gabriela and I'm super interested in an
                    old proposal of Purr <br>
                    data for GSOC, the Interaction with Audio Plugins.
                    Is the proposal still <br>
                    up? <br>
                    <br>
                    I've found a lot from vst and ladspa in the purr
                    data tree and not so <br>
                    much from lv2, so I imagine that's still an open
                    task haha :D <br>
                    <br>
                    I'm very familiarized with Pure Data - I've used it
                    in a project and I <br>
                    amuse myself with some experimental music, and I
                    would love to see some <br>
                    of my patches as plugins. Most recently I've started
                    playing with Purr <br>
                    Data and Cycling74’s Max (to see their features and
                    what could be <br>
                    brought to Purr Data). As a free software enthusiast
                    and a pd lover I <br>
                    would love to contribute to this project. <br>
                    <br>
                    I'll start to make some small contributions to warm
                    up with the code, if <br>
                    anyone has suggestions to study or more complex
                    contributions related to <br>
                    audio plugins, let me know <br>
                    <br>
                    PS: I've found this similar project for pd that may
                    relate to our goals: <br>
                    <a href="https://github.com/pierreguillot/Camomile"
                      target="_blank" moz-do-not-send="true">https://github.com/pierreguillot/Camomile</a>
                    (and could possibly be a <br>
                    baseline for part of my contribution. What do you
                    think?). <br>
                  </blockquote>
                  Hello Gabriela, <br>
                  <br>
                  Welcome! <br>
                  <br>
                  I would check prior art for the plugin project idea.
                  For example, it <br>
                  appears that <br>
                  Camomile fits your use case of turning your patches
                  into plugins. There is <br>
                  probably an external library in Pd Vanilla dealing
                  with lv2 plugins. <br>
                </blockquote>
                <br>
                Hey, I've found this external for pd: <a
                  href="https://bitbucket.org/agraef/pd-lv2plugin.git"
                  target="_blank" moz-do-not-send="true">https://bitbucket.org/agraef/pd-lv2plugin.git</a>
                I'm still working on the installation, so I haven't test
                it yet, but I think this would be more related to
                instantiating lv2 plugins inside purr-data (while
                Camomile would be more useful to transform the purr-data
                into a plugin). <br>
                <br>
                Is the pd-lv2plugin a good start for this task? <br>
              </blockquote>
            </div>
          </blockquote>
          <div><br>
          </div>
          Yes. Perhaps Albert can provide some more information on it.<br>
        </div>
      </div>
    </blockquote>
    I'm still open for this project idea, but also studying the other
    possibility.<br>
    <blockquote type="cite"
cite="mid:CAOA7yC59prpFDK15dLOPUQatStUAaFzd=-_yZJ21qycYENzeqw@mail.gmail.com">
      <div dir="ltr">
        <div class="gmail_quote"> 
          <blockquote class="gmail_quote" style="margin:0px 0px 0px
            0.8ex;border-left:1px solid
            rgb(204,204,204);padding-left:1ex">
            <div>
              <blockquote type="cite"> <br>
                <blockquote type="cite">What kind of features did you
                  find in Max/MSP that would be useful in Purr Data? <br>
                </blockquote>
                <br>
                For me the feature that would most improve the workflow
                of coding in purr-data is the autocomplete when creating
                new objects (list of fuzzy suggestions with quick
                description). <br>
                <br>
              </blockquote>
              <img src="cid:part5.415E47BB.7D81C9ED@gmail.com" alt=""
                class="" width="375" height="260"><br>
              <blockquote type="cite">Max autocompletion <br>
                <br>
                The engine of the search could be done using a fuzzy
                finder (like this project: <a
                  href="https://github.com/junegunn/fzf" target="_blank"
                  moz-do-not-send="true">https://github.com/junegunn/fzf</a>).
                <br>
                <br>
                That's an optional project that I would also be willing
                to do. Do you think that it would be interesting to the
                community and feasible? <br>
                <br>
                (Is it the elasticlunr -
                <a
href="https://git.purrdata.net/jwilkes/purr-data/-/blob/master/pd/nw/elasticlunr.js"
                  target="_blank" moz-do-not-send="true">https://git.purrdata.net/jwilkes/purr-data/-/blob/master/pd/nw/elasticlunr.js</a>
                - an attempt for this or did I completely misunderstood
                here?) <br>
              </blockquote>
            </div>
          </blockquote>
          <div><br>
          </div>
          <div>Elasticlunr is currently leveraged to build an index for
            the `<ctrl-b>` documentation browser. That index is
            cached across runs, *but* the default doesn't include
            external docs to build the index. That's good for <br>
          </div>
          <div class="gmail_quote">performance of the index builder, but
            unfortunate because there's still a lot of knowledge buried
            in the external library docs.</div>
        </div>
      </div>
    </blockquote>
    Is it really a performance issue? (I've enabled it in my i5 notebook
    and it took less than 1 second). I vote for making it the default!
    :D<br>
    <blockquote type="cite"
cite="mid:CAOA7yC59prpFDK15dLOPUQatStUAaFzd=-_yZJ21qycYENzeqw@mail.gmail.com">
      <div dir="ltr">
        <div class="gmail_quote">
          <div class="gmail_quote"><br>
          </div>
          <div class="gmail_quote">Anyhow, I think that index could be a
            good source for the autocomplete strings (as well as a good
            source for implementing tooltips).<br>
          </div>
        </div>
      </div>
    </blockquote>
    <p>I've experimented a bit with the current indexing method
      (elasticlunr) and I've found some limitations that makes me
      question if this tool would have the potential to be a good
      auto-completion engine, for example it doesn't find results if the
      query is a partial word.</p>
    <p>While playing with ripgrep
      (<a class="moz-txt-link-freetext" href="https://github.com/BurntSushi/ripgrep">https://github.com/BurntSushi/ripgrep</a>) and fzf I've found their
      search method whey more flexible, which is the main characteristic
      of an auto-completion feature. To go down this road I would run
      ripgrep after compilation to search documentation and build a
      (hidden) folder/file structure that would be shipped inside the
      installer. This structure would be used as index by fzf in runtime
      (user side) to generate autocompletion and also in the
      documentation browser. This way there will be no performance
      issues to regenerate the index (at least for built-in libraries).
      If it's of interest, we could also ship ripgrep, enabling us to
      integrate user's objects into the index.</p>
    <p>A downside of this approach is that neither libraries are web
      technologies (not compatible with purr-data for web). <br>
    </p>
    <blockquote type="cite"
cite="mid:CAOA7yC59prpFDK15dLOPUQatStUAaFzd=-_yZJ21qycYENzeqw@mail.gmail.com">
      <div dir="ltr">
        <div class="gmail_quote">
          <div class="gmail_quote">
            <div> </div>
            <div>So perhaps there's a project idea here related to a)
              doing some improvements to the doc indexing system so that
              it can include all docs by default, and b) leveraging that
              for a nice autocomplete feature.</div>
            <div><br>
            </div>
          </div>
        </div>
      </div>
    </blockquote>
    <p>I like this proposal, and I see 3 main tasks:<br>
    </p>
    <p>(a) Improve the indexing system:</p>
    <p>    - Include external docs to the index (it's already
      implemented, so it's a matter of making it the default);</p>
    <p>    - Embed in the indexing structure a hierarchy of importance
      for ranking the results based on filename and metadata: keywords,
      description, related_patches, author ...;<br>
    </p>
    <p>    - Merge results from the help file and the file itself;</p>
    <p>(b) Integrate it in the search engine of the documentation
      browser:</p>
    <p>    - Dynamically refreshing search results while typing<br>
    </p>
    <p>(c) Integrate it into a friendly drop down menu to be used when
      editing objects.</p>
    <p> What do you think?</p>
    <p><br>
    </p>
    <p>Best,</p>
    <p>Gabriela<br>
    </p>
    <blockquote type="cite"
cite="mid:CAOA7yC59prpFDK15dLOPUQatStUAaFzd=-_yZJ21qycYENzeqw@mail.gmail.com">
      <div dir="ltr">
        <div class="gmail_quote">
          <div class="gmail_quote">
            <div>Best,</div>
            <div>Jonathan<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">
              <div>
                <blockquote type="cite"> <br>
                  <blockquote type="cite">Best, <br>
                    Jonathan <br>
                    <br>
                    <blockquote type="cite">Best regards, <br>
                      <br>
                      Gabriela <br>
                      <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"
                        target="_blank" moz-do-not-send="true">https://disis.music.vt.edu/listinfo/l2ork-dev</a>
                      <br>
                    </blockquote>
                    _______________________________________________ <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"
                      target="_blank" moz-do-not-send="true">https://disis.music.vt.edu/listinfo/l2ork-dev</a>
                    <br>
                  </blockquote>
                </blockquote>
              </div>
              _______________________________________________<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>
        </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>
  </body>
</html>