[L2Ork-dev] GSOC - Audio Plugins

Mon Mar 29 13:25:23 EDT 2021

On Mon, Mar 29, 2021 at 7:16 AM Gabriela Bittencourt <
gabrielabittencourt00 at gmail.com> wrote:

>     - 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:
>
>
That second "metro" links to "metro.pd" which is definitely an outlier. It
appears it got added here:

```
commit 721fe32c2a83110020bfd772aacd83d62d245e5f
Author: Albert Graef <aggraef at gmail.com>
Date:   Mon Nov 28 14:13:07 2016 +0100

    Replace antique non-pddp metro help patch with latest version from
vanilla.
```

That commit doesn't make much sense, because metro.pd *is* a non-pddp help
patch.

Albert-- any info on what you were trying to achieve here?

Anyway, most core objects have a single help file. For external binary
libraries, the binary itself is not included in search results.

Abstractions are tricky. If there's an abstractionName-help.pd patch, we
want to show that in the search results instead of abstractionName.pd.
However, if there's an abstraction with no help patch, we probably want to
show abstractionName.pd in the results since the user can open it and
inspect the implementation. (Generally, everything should have a *-help.pd
but there are probably many undocumented abstractions in externals/.)

Try doing a search on "rev1" to see a pretty bad case. We are somehow
shipping the *-help.pd in two different directories!

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?
>

Ignoring undocumented abstractions for the moment-- in the common cases you
should be able to get the autocomplete string from the *-help.pd filename.

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

Oh, ok. I'll have a look as soon as I get a chance.

>
> "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!
>

That sounds great.

One word of warning-- I'm talking mainly from the experience of previous
years of GSoC where the project duration was longer. What you've written so
far seems feasible as I skim it-- but it is something to keep in mind.

>
> 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?
>

I'm partial to the autocomplete feature as it would be a big UX
improvement. But I'm curious what others think.

>
> PS: I've made 2 merge requests (#) into the master branch, but I saw
> everyone else is making on the emscripten branch?
>

The web app project idea is quite popular, so there's been a lot of
activity on that branch. The idea is to merge that into master, but I think
there are a few outstanding issues to address before doing so.

One detail-- the help browser does not currently work in the web app. The
doc browser builds its index in the GUI, using node.js. But in the web app
only the backend has access to whatever the emscripten file-system
abstraction is called.

Probably the solution there is to *ship* the web app with the doc browser
index, and just make a shim to load it up. I think a lot of the pieces are
already in place to do that so it shouldn't affect your project idea.

-Jonathan

> 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
>
>
> _______________________________________________
> 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/20210329/bd4400ff/attachment-0001.html>
-------------- 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/bd4400ff/attachment-0001.png>