Ticket #33 (new enhancement)

Opened 8 years ago

Last modified 8 years ago

implement a plugin browser

Reported by: kickback Assigned to: kickback
Priority: high Milestone: sweep1.0
Component: sweep Version:
Severity: normal Keywords: plugin browser
Cc:

Description (Last modified by kickback)

propose to implement a plugin browser featuring a flat list of available plugins (procedures) that is filterable by various means including. regex text match of plugin labels and matching attributes (channels:mono|stereo, type:ladspa|sweep status:blacklisted|bookmarked|unmarked)

ideally this list should be filterable and sortable but no gtk tree model exists that provides both at once so one would need to be written or found elsewhere.

the browser should be viewable either in it's own window or included in the main sweep window.

filter settings could be saved and restored as named searches, each displayed in a list in the plugin browser. default named searches could provide catagory based searching and a submenu in the main app process menu could be generated from the current settings. regex matching and process menu generation give advanced users a lot of control over what is displayed where but default settings and simple type ahead find give others an easy to use method to quickly find a particular plugin. typically you only need to type 3 letters before the list is so reduced that the target plugin can be selected.

some of this is redundant if liblrdf is used but coverage of rdf data among ladspa plugins is incomplete and liblrdf has a pretty hefty string of dependencies for such a narrow set of provided features.

Attachments

pb.png (121.8 kB) - added by kickback on 08/30/06 17:24:18.
test build showing what the plugin browser could look like (along with a sidebar and some gfx experiments)
basic_plugin_browser.diff (36.9 kB) - added by kickback on 09/21/06 04:42:43.
patch (against revison 409 which is currently trunk) to demo the basic plugin browser (called from main and displayed in it's own window in lieu of a permanent framework to host it.))

Change History

08/30/06 17:21:05 changed by kickback

  • description changed.

so far i have:

implemented a basic plugin browser interface (just for something to test really)

modified the plugin api to expose more info (plugin filename, effective channels, plugin type (currently SWEEP or LADSPA. not so useful now but might be when we support LV2) this requires that we bump the plugin api version but practically it's not a big deal as i've updated all the current plugins accordingly.

mostly implemented the filter routine (the regex label match is done but not the attribute matching)

you can add and use named searches but there's no persistent storage of those or the blacklist/bookmark toggles yet.

i'm not totally convinced that the blacklist or bookmarks are generally useful. it also means we'd need to store per plugin information then reliably associate it with it's plugin when it's loaded again. the bookmarks have no location either so it's more of a whitelist really.

the named searches give us an easily extensible category system with only a tiny amount of code. hackish but no more so than a web browsers bookmark system imo. and there isn't a comprehensive source of plugin catagory information that we could use in it's place.

see the attached screen shot to see how this could be fitted together. it's just a rough test build but layout/feature comments are welcome.

08/30/06 17:24:18 changed by kickback

  • attachment pb.png added.

test build showing what the plugin browser could look like (along with a sidebar and some gfx experiments)

09/21/06 04:42:43 changed by kickback

  • attachment basic_plugin_browser.diff added.

patch (against revison 409 which is currently trunk) to demo the basic plugin browser (called from main and displayed in it's own window in lieu of a permanent framework to host it.))

09/21/06 04:53:39 changed by kickback

i decided against adding another branch to hold the plugin browser as it's not really a stand alone feature (or at least it might not be) and the framework to host it doesn't exist yet. <weasel words>

the attached basic_plugin_browser diff is really just a sketch

to demonstrate what i'm aiming at. the changes to the plugin API need to more consideration (the effective channels should probably be enumerated rather than statically stored for example) </weasel words>

incidently, i'm wondering if this should all wait till after 1.0 is released.