Skip to content

library: search processes by tags, not just name #2095

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
edumeneses wants to merge 1 commit into
base: master
Choose a base branch
from
+20 −1
Open

library: search processes by tags, not just name #2095

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
21 changes: 20 additions & 1 deletion src/plugins/score-plugin-library/Library/RecursiveFilterProxy.cpp
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -2,6 +2,10 @@

#include "ProcessesItemModel.hpp"

#include <Process/ProcessList.hpp>

#include <score/application/GUIApplicationContext.hpp>

namespace Library
{

Expand Down Expand Up @@ -77,6 +81,21 @@ bool ProcessFilterProxy::filterAcceptsRowItself(
auto model = static_cast<ProcessesItemModel*>(sourceModel());
auto& node = model->nodeFromModelIndex(index);

return node.prettyName.contains(m_textPattern, Qt::CaseInsensitive);
if(node.prettyName.contains(m_textPattern, Qt::CaseInsensitive))
return true;

// Also match against the process tags, if any.
// The factory lookup / descriptor() call only happens when the (cheap) name
// check above fails, to keep filtering on large libraries reasonably fast.
if(auto f = score::GUIAppContext()
.interfaces<Process::ProcessFactoryList>()
.get(node.key))
{
for(const QString& tag : f->descriptor(node.customData).tags)

@jcelerier jcelerier Jul 6, 2026

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This will be super bad for performance on systems with many presets :/ as f->descriptor(node.customData) is a potentially ultra-slow operation that I did my best to make sure is not called during searching operation (which is already too slow as-is)

@edumeneses edumeneses Jul 6, 2026

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for checking and for taking care of keeping score efficiently.

New proposal: never touch descriptor() during search. Instead, precompute the tags once, when the list node is created, and store them on the node.

  • Add a QStringList tag to Library::ProcessData.
  • Populate it at node-creation time, which already happens off the search path:
  • ProcessesItemModel::rescan() / on_newPlugin() for factory-backed processes — call descriptor({}).tags there, once per factory. (Or add a cheap tags() virtual on the factory returning the static Metadata<Tags_k>, to avoid descriptor() even here.)
    • The async scanners (LV2/CLAP/VST/VST3/…) already parse the plugin metadata while building their nodes (LV2/Library.hpp reads the class label and plugin name in the same loop), so they can fill tags right there at no extra cost.
  • filterAcceptsRowItself becomes a pure in-memory match: node.prettyName.contains(pattern) || any(node.tags, contains(pattern)). No factory lookup, no descriptor(), nothing allocated per keystroke.

Claude's assessment: This stays correct across library updates: the user library is a separate repo that can change on disk at any time, but node creation is already driven by RecursiveWatch, so whenever a file/plugin is (re)added, the tags are recomputed then. Same for custom processes — factory ones flow through on_newPlugin, file/preset ones through the scanners.

Claude checked, and no LibraryInterface scanner currently derives tags from descriptor(customData) (the only per-instance descriptor() calls are in the info panel / preset detail / rendering code, not in list building), so moving tags to scan time shouldn't lose anything.

One open question: for preset/file nodes, would you rather they inherit the parent process's tags, or only carry tags the scanner extracts from the file itself? Where a scanner sets none, node.tags is empty and name search behaves as today.

Does this direction look right before I rework the PR?

if(tag.contains(m_textPattern, Qt::CaseInsensitive))
return true;
}

return false;
}
}
Loading