View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0001566||OpenMPT||Feature Request||public||2022-02-10 02:40||2022-09-11 18:37|
|Reporter||Exhale||Assigned To||Saga Musix|
|Summary||0001566: feature request ~ sample & sound font list search|
hopefully a simple search bar, possibly between the windows on the left that searches all the installed sound fonts and samples for instances of a word or phrase : eg type in snare and you will get results in the bottom of all the samples you have with that name (within your listed sample directory) and on the top all the sound fonts you have installed with that name, then delete your entry and it goes back to the usual lists - possibly wherever you left off, but obviously these details depend on you guys.
(I have a fairly extensive collection of both and I admit navigating the lists is a bit [ok I admit a lot] annoying)
This would make it much easier to find the samples / sound fonts we need... I think it could cut down the production time of many of us.
|Tags||No tags attached.|
|Has the bug occurred in previous versions?|
|Tested code revision (in case you know it)|
As of r17825 / OpenMPT 1.31.00.14, there is now a search / filter functionality for the on-disk file browser (invoke it with Ctrl+F by default, or through the context menu). This does not cover soundfonts yet - this would involve a bit more work, and I wonder if it's really worth the effort. How many soundfonts do you usally load into OpenMPT?
I have a collection of soundfonts I add to ompt, that is very much approximately 50 all together - the thing is, I have to read every one of their names when I am going through them since parts of their name/description/title things will tell you what they are, but it is rarely the first word.
Just chiming in to say I am another person with a few soundfonts floating around that contain dozens or hundreds of samples, and it'd be great to have the ability to search through them along with the file system samples. If it's expensive to open all the soundfonts to scan the instrument names each time, perhaps there could be cache stored somewhere that you only need to update when/if the modification time of the soundfont changes.
The contents (list of programs / banks) of soundfonts are already kept in memory, however due to the more complex nature of their representation in the tree view, updating the tree view in a speedy fashion after every keystroke is more complex to achieve that with the flat sample browser list. Not impossible, just more work. There's also more UI choices to make on top of that, for example: Should the bank folders remain in the tree view when filtering, or should every soundfont be turned into a flat list? If your filter only matches e.g. 3 instruments, having a flat list would probably be much better, because you don't have to manually open the folders to find those instruments, but if you just started typing and within those 50 soundfonts there are 1000 matches, you would probably not want that soundfont list to be flattened, or automatically open all folders with matching instruments. The size of the tree view would explode.
My personal recommendations would be to convert those soundfonts into individual SFZ files anyway, so that they integrate into the sample browser more naturally.
Yeah that makes sense, that is a lot of logistical stuff I didnt quite contemplate.
I'm curious, how does the new search function work when you have "Show Directories in Sample Browser" option checked? I guess that is a similar user interface problem, because it's a tree structure, but you need to filter into the tree.
I've implemented something like this before at one of my previous jobs, and the way we did it was to still show the tree, but all non-matching nodes would disappear, including the containing branches. If three leaves matched in three different branches, you would get "bare" branches that were automatically expanded to the matching leaves. We were doing some custom B2B software where our users didn't really care about UI consistency or having it look like Google or anything, so perhaps we had a bit more flexibility to do an unusual interface, but it worked pretty well.
For example, given:
If the user typed A, they would see:
In this case, "food", "fruit" and "bread" parent nodes are all still visible because at least one of their children is visible.
If the user typed AP:
Now "bread" node disappears because none of its children match.
If the user typed B:
Now "arepa" and "crêpe" nodes are not visible even though "bread" parent is visible, because they do not match. The parent/branch "match" is irrelevant, only leaf matches are considered. So if the user typed F, they would see nothing. Doesn't matter that there is a branch called "fruit".
With that approach you could also do a "start of string" match instead of "anywhere in string" match, so "A" would show "apple" and "arepa", but not "custard apple", if that seems more sensible. Probably also it would be better to only start filtering after two or three characters if you know there are hundreds of results, or add a bit of debounce, that way you don't have the problem of expanding everything unnecessarily.
The thing about only showing samples in a flat list is that some people have already organized them into directories that make it faster to find than a search if they already know exactly what they want. For example, I have lots of samples called "BD1" in different directories. If I want a TR-606 bass drum I will just go into the TR-606 directory and pick the one in there. But if I want to browse more generally through a variety of bass drums in different directories, that's when having a cross-directory view would be good. The current flat list is alright, but for me because it contains a lot of similar-named samples without any context, it's not clear what I am going to get till I preview. If I could search for a cross-reference category (filename/instrument name) while still retaining the visibility of the original category (directory/soundfont) somewhere, then I would have a bit more context about the content before I preview.
But I guess this is just different workflows for different people. It's not a big deal for me, just a "nice to have". To be honest, the main reason I haven't extracted my Soundfonts into individual samples and categorized them more cleanly is laziness - I might get round to it someday if I find a few specific instruments that I use frequently. But I can see the use case for people who want to keep everything bundled in the one file, especially if they are using the same Soundfonts as General MIDI plugins for emulators or perhaps softsynths.
Just adding this picture as an example of what another search result interface could look like. The tree is still the tree, but the flat search results include the context of which file in which directory they matched alongside them. From VS Code.
To clarify, the filter does not traverse folders recursively. Hence "Show Directories in Sample Browser" is not an issue, because you never see an actual tree - you just see the direct contents of a folder, no matter if those are folders or files.
Ah, that makes more sense. This is where I betray myself as a rookie user of the side bar bottom section. I've spent a lot of recent years composing in other apps, and am only just getting back into MPT full-time. Right now I tend to load samples by dragging them over from an existing module or just opening them directly after browsing the files another app. But looking closer at the current behavior I can understand why implementing a global search doesn't easily slot into the current UI.
hmmmm... how about this for an idea then - the top soundfont thing is trees, and you say that is where the problem mostly comes from (figuring out how to display all of this when you are actively searching. So how about this - while you are actively searching the bottom sample bar becomes the full list of search results.
That would be even more complex to implement than just any of the solutions discussed above.
alright... well thank you for the info. I will watch the conversation here from a distance because, yeah, I am not knowledgeable enough to efficiently contribute. Either way I do like to spitball and throw ideas around, but it would help if I had some knowledge of the code and how it all worked. I thought since the bottom one is already a simple list it might be easier to just throw it all in there.
|2022-02-10 02:40||Exhale||New Issue|
|2022-02-10 03:53||Exhale||Summary||feature request ~ sample list search => feature request ~ sample & sound font list search|
|2022-06-26 13:46||Saga Musix||Relationship added||has duplicate 0001609|
|2022-06-27 12:40||Saga Musix||Assigned To||=> Saga Musix|
|2022-06-27 12:40||Saga Musix||Status||new => assigned|
|2022-09-06 18:02||Saga Musix||Note Added: 0005303|
|2022-09-07 08:04||Exhale||Note Added: 0005304|
|2022-09-11 07:14||alison||Note Added: 0005308|
|2022-09-11 15:17||Saga Musix||Note Added: 0005309|
|2022-09-11 15:18||Saga Musix||Note Edited: 0005309|
|2022-09-11 15:31||Exhale||Note Added: 0005310|
|2022-09-11 16:21||alison||Note Added: 0005311|
|2022-09-11 16:31||alison||Note Added: 0005312|
|2022-09-11 16:31||alison||File Added: image.png|
|2022-09-11 16:39||Saga Musix||Note Added: 0005313|
|2022-09-11 17:40||alison||Note Added: 0005314|
|2022-09-11 18:07||Exhale||Note Added: 0005315|
|2022-09-11 18:09||Saga Musix||Note Added: 0005316|
|2022-09-11 18:37||Exhale||Note Added: 0005317|