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.
The reason I think it will be valuable is imagining this :
You want a kick - you dont want a vst kick and so you search your samples and soundfonts for 'kick' the top soundfont bar only displays soundfonts that have the word kick in them (so only the kick parts of soundfonts when the soundfonts generally have whole drum kits) and the bottom sample thing shows all the files that have the word kick, within your listed sample directory and sub directories. You then have a very easy list of kicks you can simply drag and drop to replace the one you have in the instrument tab/sample tab, taking your time to refine the sample/sound font to exactly the sound you are looking for.
That is the thing with soundfonts, 1 singular soundfont could contain a while orchestra and multiple drum kits, and often times you wont know until you click the plus button, and see that the drum section of the soundfont has stuff in it.
The reason I propose this is because once people have any large-ish collection of soundfonts, finding ones to use in a project ends up being luck or knowing a specific one well enough to browse for it specifically.
Either way, thanks for the search, if it searches samples, I think that will be a very useful tool.

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 can think of a few temporary solutions, like for example : when you start typing the sample list updates, but the soundfont list will only update when you hit the enter button. Or it waits for you to have typed 3 letters (narrowing the list down) before it updates the list, but if you hit enter on a single or double letter search your lists will explode.
I admit I am not sure how this can be solved, especially since I dont program. I will keep thinking about it and brainstorming stuff.

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:

- food
  - fruit
    . apple
    . banana
    . custard apple
  - bread
    . arepa
    . boule
    . crêpe

If the user typed A, they would see:

- food
  - fruit
    . apple
    . banana
    . custard apple
  - bread
    . arepa

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:

- food
  - fruit
    . apple
    . custard apple

Now "bread" node disappears because none of its children match.

If the user typed B:

- food
  - fruit
    . banana
  - bread
    . boule

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.

image.png (202,927 bytes)   

image.png (202,927 bytes)   

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.
So nothing happens to the top bar at all.
You start typing in the search say "k"
then in the bottom sample bar every sample with a k appears, followed by every simple individual soundfont with a k, and then the soundfont directories - those directories, if double clicked will simple expand the tree on the top bar for you to browse, while everything else will work as they presently do.

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.

As of r18221 / OpenMPT 1.31.00.18, the search filter is now also applied to sound fonts if the search is initiated from the upper half of the tree view. This version will be available from https://builds.openmpt.org/builds/ or through the Development update channel within the next few hours.

As I really don't use sound fonts this way, it's difficult to judge how usable this feature is in its current state. Please provide some feedback how it works for you.

The search filter was not cleared for soundfonts when changing directories in the sample browser, potentially leaving them in a filtered state while no filter was active. r18231 fixes this.

Ok so I decided that today I would finally check this out and give it a test...
I think there needs to be something added to the help section about it if you havent already - just a simple "When something in the tree view is selected, press ctrl-f to find specific sounds in your list" will be all that is needed I think. But I guessed that anyways and was greeted with exactly what I had imagined, a simple search bar in the exact spot I imagined it would be :)
I tested it by searching kick, and even though it brought up a lot of sf2 files without any use, it did very much help my search by bringing up some specific ones that just have kicks in them. I can see this being very extremely helpful as it is already. I am sure you guys will want to refine it, and maybe the way it is working is exactly how you want it to work - i imagine the useless ones simply didnt have specific results but you wanted to keep them on the list anyways for a very good reason... but over all I can see myself using this a heck of a lot. Thank you very much.

a screenshot of the results I got

search results.png (29,423 bytes)   

search results.png (29,423 bytes)   

Once again, This will be insanely useful, thank you very much!

I think there needs to be something added to the help section about it if you havent already

The manual will be updated close to the 1.31 release, otherwise those changes would also appear in the manual of future 1.30 updates, where they are not applicable.

it brought up a lot of sf2 files without any use

It doesn't "bring up" SF2 files without use - a file without any matches is just not removed from the tree, just like the instrument library itself won't disappear when there are no matches inside it. I guess it would be possible to just hide any soundfonts that don't contain any matches, but it would make the navigation in the list a lot more unstable, as more matches on the top level appear and disappear as you type.

great stuff :) we dont want to make it unstable - got it. As I thought, there is a good reason. It is very useful as is and I can see myself using it a heck of a lot.
I admit I imagined it always being there (not needing a ctrl-f to bring up) with a magnifying glass on the left so it was obviously a search, but this is intuitive too, and certainly adding the instructions of how to use it would understandably only need to happen when it is officially added.
Good stuff dude, and a lovey addition for xmas I might add :) even if it doesnt get added officially by xmas it is great to have it in the snapshots. Have a great one Saga, and I hope you and your family have a jolly time.

we dont want to make it unstable - got it

Just to be clear, I don't mean that the program could crash or something . I just think the feeling of a list where the top-level items keep disappearing and showing up would be very unstable and may make browsing with the keyboard (you can press arrow up / down while typing into the search) more surprising. Anyway, I'm not too invested into either of the options, so as of r18475 the soundfonts are now removed completely from the tree view if they don't contain any matches. Let me know if this works better for you.

Thanks, went to check it out, but I dont know what file that link is - I thought it would be a new snapshot. what is view_tre.cpp? And I just went to the old links you posted thinking that the new snapshots would be at the place and something weird had just happened, but I guess you guys changed the system... I dont know what to do... I will look around some more...
ok, I am sorry, but I have no clue how to download the new snap, yet alone test it.

[edit] ok I found the https://builds.openmpt.org/builds/ link you posted before and I must have used... going to see if I can find the version you talked about here...
downloading...

ok yes yes, very much yes... this is far more efficient and less distracting!
Very intuitive! That is the way I would release the feature given the choice!
great stuff!
What I like about this is it feels like the same treatment that the vsts get when you are searching them. Consistent :)
edit 1 -
ok scratch that (just a bit) I did a basic kick search, and it responded well when updating the list, then, after being thoroughly impressed I decided to try another search and cleared the search bar... and now my ompt is hanging - I am probably going to have to kill it. (yup had to kill it)
So yeah, maybe this isnt the best idea.
edit 2 -
ok tried again, and it worked fine this time... hmmm... I think it is a bit unstable though
edit 3 -
ok I decided to put it through its paces and yup it got hung up again / basically crashed - this time on my third search. I did a kick search, grabbed one, did a snare search, grabbed one, and on the third search for 'hat' (it only got to 'ha' before hanging) basically my ompt is in a death spiral - I will have to kill it. I killed it.
I will keep you updated on my trials here, but I do know that ompt takes crash logs, even though I have no clue where it puts them - I am getting sleepy now, so I will try searching in the morning since I am sure someone must have covered that topic somewhere on the forums or maybe in the help section on ompt. For now, tonight's trials are over.