<div dir="ltr"><div dir="ltr">On Sat, Mar 27, 2021 at 2:20 PM Gabriela Bittencourt <<a href="mailto:gabrielabittencourt00@gmail.com">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">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"><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">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">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:17874f1c3b4d26158931" alt="" 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">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">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><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">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><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><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><br></div><div>For "b", the index has already been generated so this is pure javascript and also subject to quick iteration.</div><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.<br></div><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><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><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">L2Ork-dev@disis.music.vt.edu</a>
<br>
<a href="https://disis.music.vt.edu/listinfo/l2ork-dev" target="_blank">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">L2Ork-dev@disis.music.vt.edu</a>
<br>
<a href="https://disis.music.vt.edu/listinfo/l2ork-dev" target="_blank">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">L2Ork-dev@disis.music.vt.edu</a><br>
<a href="https://disis.music.vt.edu/listinfo/l2ork-dev" rel="noreferrer" target="_blank">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">L2Ork-dev@disis.music.vt.edu</a>
<a href="https://disis.music.vt.edu/listinfo/l2ork-dev" target="_blank">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">L2Ork-dev@disis.music.vt.edu</a><br>
<a href="https://disis.music.vt.edu/listinfo/l2ork-dev" rel="noreferrer" target="_blank">https://disis.music.vt.edu/listinfo/l2ork-dev</a></blockquote></div></div></div>