<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>On 27/03/2021 20:47, Jonathan Wilkes wrote:<br>
</p>
<blockquote type="cite"
cite="mid:CAOA7yC6gSJqA-uTYF5Rs_E_tLKh45bMFi_o07yq5JMd4G9nO8Q@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div dir="ltr">
<div dir="ltr">On Sat, Mar 27, 2021 at 2:20 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>Hello,<br>
</p>
<div>On 26/03/2021 19:14, Jonathan Wilkes wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">
<div dir="ltr">On Fri, Mar 26, 2021 at 12:42 PM
Gabriela Bittencourt <<a
href="mailto:gabrielabittencourt00@gmail.com"
target="_blank" 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>
</div>
</blockquote>
<div><br>
</div>
<div>Sounds good.<br>
</div>
<div> </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">
<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:part6.678CAB4A.2375659E@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>
</div>
</blockquote>
<div><br>
</div>
<div class="gmail_quote">When I measured it on Windows 7/10 it
took at least an order of magnitude longer than on Linux.<br>
</div>
</div>
</div>
</blockquote>
<p>Ah, ok. Yes, I've only tested it on Linux (Ubuntu 20.04). If I'm
accepted to gsoc, I'll install a windows aside with my linux to
test my alterations on both.</p>
<blockquote type="cite"
cite="mid:CAOA7yC6gSJqA-uTYF5Rs_E_tLKh45bMFi_o07yq5JMd4G9nO8Q@mail.gmail.com">
<div dir="ltr">
<div class="gmail_quote">
<div class="gmail_quote">
<div> </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">
<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. <br>
</p>
</div>
</blockquote>
</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>While playing with ripgrep (<a
href="https://github.com/BurntSushi/ripgrep"
target="_blank" moz-do-not-send="true">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>
</div>
</blockquote>
<div><br>
</div>
<div>With Purr Data I try to keep soft realtime scheduling
techniques in mind for the development process itself. So:</div>
<div><br>
</div>
<div>1. Making a pure Javascript or pure C change: worst
case performance n minutes</div>
<div>2. Making a change that requires sending a message
between frontend and backend: worst case n * 4 minutes</div>
<div>3. Making a change that requires a node.js method which
touches the filesystem: worst case n * 10 (i.e., you have
to test on Windows which is always the outlier)<br>
</div>
<div>4. Adding a dependency: worst case n * 100 (because of
ongoing maintenance, e.g., when that version number
changes from a 3 to a 4 in the package manager)</div>
<div>5. Using one of the nw.js methods that is neither
node.js nor pure Javascript: worst case n * 1000 (because
they are eternally buggy)</div>
</div>
</div>
</div>
</blockquote>
<p>Yeah, it makes sense.</p>
<p>I've revisited elasticlunr project and I tried to extract the
most of it (merge request: <a
href="https://git.purrdata.net/jwilkes/purr-data/-/merge_requests/715">https://git.purrdata.net/jwilkes/purr-data/-/merge_requests/715</a>),
but it still has some limitations. I've found fuse.js which has
more options, and still respects the mentioned directives (pure js
without dependencies).</p>
<blockquote type="cite"
cite="mid:CAOA7yC6gSJqA-uTYF5Rs_E_tLKh45bMFi_o07yq5JMd4G9nO8Q@mail.gmail.com">
<div dir="ltr">
<div class="gmail_quote">
<div class="gmail_quote">
<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>
<p> </p>
<blockquote type="cite">
<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>
</div>
</blockquote>
<div><br>
</div>
<div>I'm not sure what this bullet point means. What does
"the file itself" refer to here?<br>
</div>
</div>
</div>
</div>
</blockquote>
<p>Let's take the example, when we search for "metro", we get the
following results:<br>
</p>
<p><img src="cid:part11.7CAF746B.59113856@gmail.com" alt=""></p>
<p>The first is "metro-help.pd" and the second is "metro.pd". My
proposition is to merge both files into one index, gathering more
info in the same index item. In the browser documentation we could
always link to the help file (when present), and in the
autocomplete dropdown we could link to the object.pd. What do you
think?<br>
</p>
<blockquote type="cite"
cite="mid:CAOA7yC6gSJqA-uTYF5Rs_E_tLKh45bMFi_o07yq5JMd4G9nO8Q@mail.gmail.com">
<div dir="ltr">
<div class="gmail_quote">
<div class="gmail_quote">
<div> </div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">
<div>
<p>(b) Integrate it in the search engine of the
documentation browser:</p>
<p> - Dynamically refreshing search results while
typing <br>
</p>
</div>
</blockquote>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">
<div>
<p> </p>
<p>(c) Integrate it into a friendly drop down menu to be
used when editing objects.</p>
<p> What do you think?</p>
</div>
</blockquote>
<div><br>
</div>
<div>It sounds doable for sure.<br>
</div>
<div><br>
</div>
<div>The tasks of "a" above are mostly pure javascript, and
I don't *think* it requires any changes to the currently
used node.js methods. So that is probably subject to quick
iteration and improvement.</div>
</div>
</div>
</div>
</blockquote>
<blockquote type="cite"
cite="mid:CAOA7yC6gSJqA-uTYF5Rs_E_tLKh45bMFi_o07yq5JMd4G9nO8Q@mail.gmail.com">
<div dir="ltr">
<div class="gmail_quote">
<div class="gmail_quote">
<div><br>
</div>
<div>For "b", the index has already been generated so this
is pure javascript and also subject to quick iteration.</div>
</div>
</div>
</div>
</blockquote>
<p>I've implemented the task "b" and second bullet of task "a"
(hierarchy of priorities) as a proof of concept, merge request
#715.</p>
<blockquote type="cite"
cite="mid:CAOA7yC6gSJqA-uTYF5Rs_E_tLKh45bMFi_o07yq5JMd4G9nO8Q@mail.gmail.com">
<div dir="ltr">
<div class="gmail_quote">
<div class="gmail_quote">
<div><br>
</div>
<div>"c" would have the most work in terms of UI changes and
getting the UX right. But again, pure javascript <br>
</div>
<div>and HTML5 so quick iteration here, too.</div>
<div><br>
</div>
<div>With that in mind, I think it's worth investigating the
current search indexing method and leveraging that to get
an initial list of object creator names, and to stay in
the domain of pure JS (including any pure JS libs if those
are needed).<br>
</div>
<div><br>
</div>
<div>Hint-- It has been a long-standing rule that it's a bug
to ship an external binary without a help patch. So most
should have an objectName-help.pd patch, and the outlier
externals (as well as outlier core objects) can be dealt
with as a handful of special cases.</div>
</div>
</div>
</div>
</blockquote>
<blockquote type="cite"
cite="mid:CAOA7yC6gSJqA-uTYF5Rs_E_tLKh45bMFi_o07yq5JMd4G9nO8Q@mail.gmail.com">
<div dir="ltr">
<div class="gmail_quote">
<div class="gmail_quote">
<div> <br>
</div>
<div>A few other ideas:</div>
<div>* dealing with object arguments and message box
content. I love the way DevTools will remember entire
commands, even across instances. So perhaps a way to add
previously entered box content</div>
</div>
</div>
</div>
</blockquote>
That sounds feasible.<br>
<blockquote type="cite"
cite="mid:CAOA7yC6gSJqA-uTYF5Rs_E_tLKh45bMFi_o07yq5JMd4G9nO8Q@mail.gmail.com">
<div dir="ltr">
<div class="gmail_quote">
<div class="gmail_quote">
<div><br>
</div>
<div>* a way to automatically add docs in index when the
user adds a new path, either globally through <br>
</div>
<div>preferences or by instantiating a `[declare]` with a
path or lib. Although this could get tricky and may be out
of scope for this particular project. (I.e., requires
crossing between GUI and backend wrt `[declare]`)</div>
</div>
</div>
</div>
</blockquote>
<p>Cool, it would improve the robustness of the feature! I would ask
more help for this bullet than the previous ones, but I'm excited
to do it and learn in the process!</p>
<p><br>
</p>
<p>For the GSOC application, what feature is the most
urgent/interesting to purr data community? The project of the
audio plugins; this one for autocomplete; or the suggested ideas
for gsoc'21?</p>
<p><br>
</p>
<p>PS: I've made 2 merge requests (#) into the master branch, but I
saw everyone else is making on the emscripten branch?<br>
</p>
<blockquote type="cite"
cite="mid:CAOA7yC6gSJqA-uTYF5Rs_E_tLKh45bMFi_o07yq5JMd4G9nO8Q@mail.gmail.com">
<div dir="ltr">
<div class="gmail_quote">
<div class="gmail_quote">
<div><br>
</div>
<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>
<p><br>
</p>
<p>Best,</p>
<p>Gabriela<br>
</p>
<blockquote type="cite">
<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></fieldset>
<pre>_______________________________________________
L2Ork-dev mailing list
<a href="mailto:L2Ork-dev@disis.music.vt.edu" target="_blank" moz-do-not-send="true">L2Ork-dev@disis.music.vt.edu</a>
<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></pre>
</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>