It would be awesome if:
· the buttons on the toolbar toogle show/hide the tools (now only shows, but doesn't close)

This is an interesting idea.
However, it's not clear to me whether this would be an improvement in all respects:

• Currently, pressing a button doesn't just make the window visible, it also focuses it (i.e. puts it in front of any other windows). For a button with show/hide functionality, the question is whether the show operation should focus the window too. If it doesn't, the user doesn't have the ability to quickly focus the window. But if the show operation does focus the window, then the order in which the user presses the buttons becomes crucial when windows overlap, which seems undesired; and when a particular window is underneath another window, the user has to press the button of the underlying window twice to focus it.
• Making the corresponding items in the menu of the main window work in show/hide fashion too would probably be bad (particularly for visually impaired users), since the user has to look at the current state (indicated by a tick of front of the menu item) to know what executing the menu item will do. But if only the buttons and not the menu items work in show/hide fashion, there is no longer a match between them, which could be confusing to some users. People have already complained about the "steep learning curve" of some of my applications (in particular BC Manager), so I've learned to be very wary about adding more complexity.
• If the buttons on the toolbar work as show/hide toggles, they become visibility indicators. But then it would become logical to have the visibility of ALL windows indicated by these buttons. However, in MIDI Tools this would lead to 14 show/hide buttons. So the main window would have to be bigger, which some users might not like. (For instance, I know that some users use MIDI Tools only for its Mackie monitors, on top of their DAW application.) Having 14 show/hide buttons would also lose the current idea of only having buttons for the most commonly required windows.
• Currently my applications have a system that allows the user to quickly switch between window setups: the "desktop" system, available via View -> Desktop. For example, a user could have one such "desktop" with Mackie monitors, another with MIDI input/output monitors for testing, etc. So to some extent, these desktops can do what you're proposing to do by pressing multiple show/hide buttons. For complicated switches, the desktop system is probably quicker: e.g. "Alt+V, D, <number>" will switch to the desired desktop. And again, in terms of user experience, I'm wary about having too many different systems providing partially overlapping functionality.
• Finally, a practical, but serious problem is that I don't know how to put the type of button currently used ("speedbutton") in a permanent "down" state. So I would probably have to switch to a different button type. In fact, I don't know any standard Delphi/Lazarus button type that does this, so it would probably be a lot of work to implement this. (Delphi is used for the Windows editions of my applications, Lazarus for the macOS editions. So the type of button should exist in both Delphi and Lazarus.)

To summarize: I can see that having show/hide buttons can useful to certain users in certain situations, but at the moment the disadvantages seem to outweigh the advantages. I'll have to think about it, and of course find a button type that can do this in the first place...

were possible to use the pc's keyboard to play the piano (just like kontakt does, including the octaves)

The keyboard window was never meant to be used as a serious playing tool.
For instance, this is why the arpeggio feature uses Windows' light-weight but inaccurate timing system, which can easily lead to hiccups.
This is also why I haven't bothered implementing the use of the computer keyboard for playing notes.
One problem is that not every computer keyboard uses QWERTY: some countries have AZERTY, some QWERTZ, etc. Maybe it is possible to use the computer keyboard's underlying scan codes (which should be the same); but still, in the end it may be best to make the assignments user-customizable, which of course will make things more complicated. So I can't promise anything, but I'll look into it.

   Mark.

Hello!
What about minimizing to tray?
Thank you!