[L2Ork-dev] GSOC - Audio Plugins

Sat Mar 27 15:47:22 EDT 2021

On Sat, Mar 27, 2021 at 2:20 PM Gabriela Bittencourt <
gabrielabittencourt00 at gmail.com> wrote:

> Hello,
> On 26/03/2021 19:14, Jonathan Wilkes wrote:
>
> On Fri, Mar 26, 2021 at 12:42 PM Gabriela Bittencourt <
> gabrielabittencourt00 at gmail.com> wrote:
>
>> 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
>> On 26/03/2021 17:27, Gabriela Bittencourt wrote:
>>
>> On 26/03/2021 15:04, Jonathan Wilkes wrote:
>>
>> On Fri, Mar 26, 2021 at 5:36 AM Gabriela Bittencourt
>> <gabrielabittencourt00 at gmail.com> <gabrielabittencourt00 at gmail.com>
>> wrote:
>>
>> Hello everyone,
>>
>> My name is Gabriela and I'm super interested in an old proposal of Purr
>> data for GSOC, the Interaction with Audio Plugins. Is the proposal still
>> up?
>>
>> I've found a lot from vst and ladspa in the purr data tree and not so
>> much from lv2, so I imagine that's still an open task haha :D
>>
>> I'm very familiarized with Pure Data - I've used it in a project and I
>> amuse myself with some experimental music, and I would love to see some
>> of my patches as plugins. Most recently I've started playing with Purr
>> Data and Cycling74’s Max (to see their features and what could be
>> brought to Purr Data). As a free software enthusiast and a pd lover I
>> would love to contribute to this project.
>>
>> I'll start to make some small contributions to warm up with the code, if
>> anyone has suggestions to study or more complex contributions related to
>> audio plugins, let me know
>>
>> PS: I've found this similar project for pd that may relate to our goals:
>> https://github.com/pierreguillot/Camomile (and could possibly be a
>> baseline for part of my contribution. What do you think?).
>>
>> Hello Gabriela,
>>
>> Welcome!
>>
>> I would check prior art for the plugin project idea. For example, it
>> appears that
>> Camomile fits your use case of turning your patches into plugins. There
>> is
>> probably an external library in Pd Vanilla dealing with lv2 plugins.
>>
>>
>> Hey, I've found this external for pd:
>> https://bitbucket.org/agraef/pd-lv2plugin.git 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).
>>
>> Is the pd-lv2plugin a good start for this task?
>>
>>
> Yes. Perhaps Albert can provide some more information on it.
>
> I'm still open for this project idea, but also studying the other
> possibility.
>

Sounds good.

>
>>
>>
>> What kind of features did you find in Max/MSP that would be useful in
>> Purr Data?
>>
>>
>> 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).
>>
>>
>> Max autocompletion
>>
>> The engine of the search could be done using a fuzzy finder (like this
>> project: https://github.com/junegunn/fzf).
>>
>> 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?
>>
>> (Is it the elasticlunr -
>> https://git.purrdata.net/jwilkes/purr-data/-/blob/master/pd/nw/elasticlunr.js
>> - an attempt for this or did I completely misunderstood here?)
>>
>>
> 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
> performance of the index builder, but unfortunate because there's still a
> lot of knowledge buried in the external library docs.
>
> 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
>

When I measured it on Windows 7/10 it took at least an order of magnitude
longer than on Linux.

>
> Anyhow, I think that index could be a good source for the autocomplete
> strings (as well as a good source for implementing tooltips).
>
> 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.
>
While playing with ripgrep (https://github.com/BurntSushi/ripgrep) 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.
>
> A downside of this approach is that neither libraries are web technologies
> (not compatible with purr-data for web).
>

With Purr Data I try to keep soft realtime scheduling techniques in mind
for the development process itself. So:

1. Making a pure Javascript or pure C change: worst case performance n
minutes
2. Making a change that requires sending a message between frontend and
backend: worst case n * 4 minutes
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)
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)
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)

> 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.
>
> I like this proposal, and I see 3 main tasks:
>
> (a) Improve the indexing system:
>
>     - Include external docs to the index (it's already implemented, so
> it's a matter of making it the default);
>
>     - Embed in the indexing structure a hierarchy of importance for
> ranking the results based on filename and metadata: keywords, description,
> related_patches, author ...;
>
>     - Merge results from the help file and the file itself;
>

I'm not sure what this bullet point means. What does "the file itself"
refer to here?

> (b) Integrate it in the search engine of the documentation browser:
>
>     - Dynamically refreshing search results while typing
>
(c) Integrate it into a friendly drop down menu to be used when editing
> objects.
>
> What do you think?
>

It sounds doable for sure.

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.

For "b", the index has already been generated so this is pure javascript
and also subject to quick iteration.

"c" would have the most work in terms of UI changes and getting the UX
right. But again, pure javascript
and HTML5 so quick iteration here, too.

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).

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.

A few other ideas:
* 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

* a way to automatically add docs in index when the user adds a new path,
either globally through
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]`)

Best,
Jonathan

> Best,
>
> Gabriela
>
> Best,
> Jonathan
>
>
>> Best,
>> Jonathan
>>
>> Best regards,
>>
>> Gabriela
>>
>> _______________________________________________
>> L2Ork-dev mailing list
>> L2Ork-dev at disis.music.vt.edu
>> https://disis.music.vt.edu/listinfo/l2ork-dev
>>
>> _______________________________________________
>> L2Ork-dev mailing list
>> L2Ork-dev at disis.music.vt.edu
>> https://disis.music.vt.edu/listinfo/l2ork-dev
>>
>> _______________________________________________
>> L2Ork-dev mailing list
>> L2Ork-dev at disis.music.vt.edu
>> https://disis.music.vt.edu/listinfo/l2ork-dev
>
>
> _______________________________________________
> L2Ork-dev mailing listL2Ork-dev at disis.music.vt.eduhttps://disis.music.vt.edu/listinfo/l2ork-dev
>
> _______________________________________________
> L2Ork-dev mailing list
> L2Ork-dev at disis.music.vt.edu
> https://disis.music.vt.edu/listinfo/l2ork-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://disis.music.vt.edu/pipermail/l2ork-dev/attachments/20210327/b4a2d5d0/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: max_autocomplete.jpeg
Type: image/jpeg
Size: 31497 bytes
Desc: not available
URL: <http://disis.music.vt.edu/pipermail/l2ork-dev/attachments/20210327/b4a2d5d0/attachment-0001.jpeg>