[L2Ork-dev] GSOC - Audio Plugins
Gabriela Bittencourt
gabrielabittencourt00 at gmail.com
Sat Mar 27 14:20:47 EDT 2021
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
> <mailto: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>
>>> <mailto: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
>>>> <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
>> <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.
>
>>
>>> 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
>> <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
>> <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
>
> 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).
> 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;
(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?
Best,
Gabriela
> Best,
> Jonathan
>
>>
>>> Best,
>>> Jonathan
>>>
>>>> Best regards,
>>>>
>>>> Gabriela
>>>>
>>>> _______________________________________________
>>>> L2Ork-dev mailing list
>>>> L2Ork-dev at disis.music.vt.edu <mailto:L2Ork-dev at disis.music.vt.edu>
>>>> https://disis.music.vt.edu/listinfo/l2ork-dev
>>>> <https://disis.music.vt.edu/listinfo/l2ork-dev>
>>> _______________________________________________
>>> L2Ork-dev mailing list
>>> L2Ork-dev at disis.music.vt.edu <mailto:L2Ork-dev at disis.music.vt.edu>
>>> https://disis.music.vt.edu/listinfo/l2ork-dev
>>> <https://disis.music.vt.edu/listinfo/l2ork-dev>
> _______________________________________________
> L2Ork-dev mailing list
> L2Ork-dev at disis.music.vt.edu <mailto:L2Ork-dev at disis.music.vt.edu>
> https://disis.music.vt.edu/listinfo/l2ork-dev
> <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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://disis.music.vt.edu/pipermail/l2ork-dev/attachments/20210327/741f6a8f/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/741f6a8f/attachment-0001.jpeg>
More information about the L2Ork-dev
mailing list