[L2Ork-dev] GSOC - Audio Plugins
Gabriela Bittencourt
gabrielabittencourt00 at gmail.com
Mon Mar 29 07:10:55 EDT 2021
On 27/03/2021 20:47, Jonathan Wilkes wrote:
> On Sat, Mar 27, 2021 at 2:20 PM Gabriela Bittencourt
> <gabrielabittencourt00 at gmail.com
> <mailto: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
>> <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.
>
>
> 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
>>> <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
>
>
> When I measured it on Windows 7/10 it took at least an order of
> magnitude longer than on Linux.
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.
>>
>> 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
> <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)
Yeah, it makes sense.
I've revisited elasticlunr project and I tried to extract the most of it
(merge request:
https://git.purrdata.net/jwilkes/purr-data/-/merge_requests/715
<https://git.purrdata.net/jwilkes/purr-data/-/merge_requests/715>), 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).
>
>> 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?
Let's take the example, when we search for "metro", we get the following
results:
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?
> (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.
I've implemented the task "b" and second bullet of task "a" (hierarchy
of priorities) as a proof of concept, merge request #715.
>
> "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
That sounds feasible.
>
> * 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]`)
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!
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?
PS: I've made 2 merge requests (#) into the master branch, but I saw
everyone else is making on the emscripten branch?
>
> Best,
> Jonathan
>
>
> 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 <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/20210329/049eb8d5/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/20210329/049eb8d5/attachment-0001.jpeg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ccfbimakopkpdjdj.png
Type: image/png
Size: 5465 bytes
Desc: not available
URL: <http://disis.music.vt.edu/pipermail/l2ork-dev/attachments/20210329/049eb8d5/attachment-0001.png>
More information about the L2Ork-dev
mailing list