It looks that the author of the underlying NimBLE-library added a callback for scanned devices:
h2zero/NimBLE-Arduino#439
Maybe this could be a good starting point for implementing the requested functionality?

It looks that the author of the underlying NimBLE-library added a callback for scanned devices: h2zero/NimBLE-Arduino#439 Maybe this could be a good starting point for implementing the requested functionality?

Thank you. Now I need to learn how to use it. I am a beginner as far as Arduino programming is concerned.
What I would like to do is to press a button to discover and connect to a discovered device, and then always connect to that device, until I press the button at power ON to connect to another discovered device. So basically just finding a device and saving it somewhere.

I think that the new callback method for scanned devices will really simplify your project, as this callback invokes a piece of code (the respective callback method) when a BLE-MIDI service was found. In this callback method you can implement what should happen when a BLE-MIDI service was found. An alternative might be to connect to the first BLE-MIDI-service that is found, determine the name of the device and disconnect again when this is not the device of your choice. But this approach will only work if the next connection will target the next available BLE-MIDI device. Just give it a try ...

If the preferred BLE-MIDI device to be connected to should be kept even when the Arduino microcontroller is powered off than you need a special area where you store the device data persistently.

Some challenges are about to be mastered – but this is a lot of fun😉

I think that is what that web server code for connecting to a WiFi hotspot and then save it does. I think it saves in SPIFFS. This library could eventually do the same. The problem would be conflicts when using both of them? The other code also allows to flash the board over the air, which is cool. I tend to always use that method on the devices I build for myself. But as I said, I am a total beginner. :)

Client BLE needs to use the same method that the other transport layer (same functions names, same arguments in functions, etc.) to be compatible with the BLE Midi library. Because of this, it's not possible to add a new function adding a scanning result method.

On the other way, a develop branch exists that allow prints by console each midi server found
https://github.com/RobertoHE/Arduino-BLE-MIDI/tree/CustomSettings. This branch is actually under merge request to the main branch adding some configurable settings to MIDI BLE Client.
You can add #define MIDIBLECLIENTVERBOSE before #include lib for enabling verbose of Client BLE. With this verbose, ESP32 prints by console every MIDI server that is finding in each scanner. It does not allow the use of the midi server found in the code, but you can have a reference for help.

The CustomSettings branch is under construction (NimBLE32 is kinda OK, now making it work for the native BLE Lib and the Arduino BLE lib)

I'm stuck on the CustomSettings, not sure how to proceed - branch is now unable to merge :(
What is a way forward @RobertoHE ?

Soory. I dont understand you. Would you give some more info? Do you need translate the other classes to customSetting grammar or do you merge the branch with main?

@RobertoHE Hi, yes, I'm sorry, I should have provided more context, in all my enthusiasm when accepting PR's & adding code. Branch CustomSettings can't be merged automatically into the main branch :(
As you indicated, we (you) can again add the templates to the classes, or we find a way to merge (albeit not automatically). (I know the normal git commands, but not more complicated ones.
Can you help?

What errors do you see when you tied to merge?

Good hint @RobertoHE, I see the conflicting errors and can deals with them myself - but will ask you to test

https://stackoverflow.com/questions/31973318/github-cant-automatically-merge
https://docs.github.com/es/pull-requests/collaborating-with-pull-requests/addressing-merge-conflicts/resolving-a-merge-conflict-using-the-command-line

I'm afraid that you must merge it manually. It isn't hard, but you need to expend some time and select manually what conflict is the correct.

Done, please check the master branch - thanks @RobertoHE

Well done @lathoub.
Unfortunately, I do not have any ESP32 board or IDE code compiler now (and the 4 next weeks neither) to test it. You would use the "customBufferSize" example like the base project and try to compile modifying some options (try different transport layers and their heritages settings). Sorry for not being more helpful at this moment.
If everything compiles ok, it will be a good thing.

Please. Check #102 pull request.