View Issue Details

IDProjectCategoryView StatusLast Update
0001566OpenMPTFeature Requestpublic2022-09-11 18:37
ReporterExhale Assigned ToSaga Musix  
PrioritynoneSeverityfeatureReproducibilityN/A
Status assignedResolutionopen 
Summary0001566: feature request ~ sample & sound font list search
Description

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.

TagsNo tags attached.
Has the bug occurred in previous versions?
Tested code revision (in case you know it)

Relationships

has duplicate 0001609 closed Add a search query function to the Sample Tree view 

Activities

Saga Musix

Saga Musix

2022-09-06 18:02

administrator   ~0005303

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?

Exhale

Exhale

2022-09-07 08:04

reporter   ~0005304

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.

alison

alison

2022-09-11 07:14

reporter   ~0005308

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.

Saga Musix

Saga Musix

2022-09-11 15:17

administrator   ~0005309

Last edited: 2022-09-11 15:18

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.

Exhale

Exhale

2022-09-11 15:31

reporter   ~0005310

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.

alison

alison

2022-09-11 16:21

reporter   ~0005311

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.

alison

alison

2022-09-11 16:31

reporter   ~0005312

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)   
Saga Musix

Saga Musix

2022-09-11 16:39

administrator   ~0005313

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.

alison

alison

2022-09-11 17:40

reporter   ~0005314

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.

Exhale

Exhale

2022-09-11 18:07

reporter   ~0005315

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.

Saga Musix

Saga Musix

2022-09-11 18:09

administrator   ~0005316

That would be even more complex to implement than just any of the solutions discussed above.

Exhale

Exhale

2022-09-11 18:37

reporter   ~0005317

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.

Issue History

Date Modified Username Field Change
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