GUI: piano keyboard

Get help with using AutoHotkey (v1.1 and older) and its commands and hotkeys
User avatar
Drugwash
Posts: 850
Joined: 29 May 2014, 21:07
Location: Ploieşti, Romania
Contact:

Re: GUI: piano keyboard

03 May 2018, 03:59

I've just tested and indeed the destroying of the VK window is the cause. I've partly fixed it as explained above but this creates problems with changing layouts so it'll take a little more work. After that the delays will no longer be required.
Part of my AHK work can be found here.
User avatar
rommmcek
Posts: 1470
Joined: 15 Aug 2014, 15:18

Re: GUI: piano keyboard

03 May 2018, 04:42

This works perfectly:

Code: Select all

HideKeys(wP, lP, msg, hwnd)
{
Global
KeyWait, Rbutton
If (hwnd=hWnd2)
	GoSub 2GuiClose
Else If (hwnd=hPreview)
	GoSub 3GuiClose
}
Edit: Sorry, the site was striking, wrong paste etc... At the end it's very simple!
User avatar
Drugwash
Posts: 850
Joined: 29 May 2014, 21:07
Location: Ploieşti, Romania
Contact:

Re: GUI: piano keyboard

03 May 2018, 05:22

KeyWait inside a WM_* function? Nah… ;)

Try this version, please:
Klavier hero MOD 1.3.1.7z
(12.55 KiB) Downloaded 111 times
v1.3.1:
- fixed context-menu activation on hiding virtual keyboard window
- virtual keyboard redraws faster now when switching layouts
- preview window is now optional
- preview window position and visibility are now saved/restored between sessions
Part of my AHK work can be found here.
User avatar
rommmcek
Posts: 1470
Joined: 15 Aug 2014, 15:18

Re: GUI: piano keyboard

03 May 2018, 06:02

- Thanks for reminder (WM_*)
- 1.3.1 works just fine
- You need to uncheck the check box when preview win has been hidden.

bye for today
User avatar
Drugwash
Posts: 850
Joined: 29 May 2014, 21:07
Location: Ploieşti, Romania
Contact:

Re: GUI: piano keyboard

03 May 2018, 06:12

And thank you for testing and feedback.
That checkbox is a generic toogle. When checkbox is on and preview is hidden, on layout change it will be shown. When checkbox is off, preview will never be shown. It's by design. ;)
I could add a small button to show preview on demand.

Have a nice day! :)
Part of my AHK work can be found here.
User avatar
Drugwash
Posts: 850
Joined: 29 May 2014, 21:07
Location: Ploieşti, Romania
Contact:

Re: GUI: piano keyboard

03 May 2018, 09:12

This should be enough for today. If everything works correctly, next I'll try to focus on actual MIDI features.
Klavier hero MOD 1.3.2.7z
(12.76 KiB) Downloaded 104 times
v1.3.2:
- minor code cleanup
- added small button for toggling preview window
- character hints on keys are now optional

And a bonus: my five tiny "nephews" (and/or "nieces" ?) born Saturday April 28th, courtesy my cat-"daughter" Lily. You can see the white still oppress the black and there's nothing I can do about it. :P :lol:
PICT3288a.jpg
PICT3288a.jpg (175.63 KiB) Viewed 4200 times
Part of my AHK work can be found here.
User avatar
rommmcek
Posts: 1470
Joined: 15 Aug 2014, 15:18

Re: GUI: piano keyboard

03 May 2018, 23:59

- All functionalities seem to work fine.
- Three controls for keyboard layout info, nearly too much of the good.
- Responsiveness of the keyboard is better compared to the orignal version (i.e. conversion), but my version is still more sensitive, however orignal has the lowest Midi latency.

- Bad news: Yesterday I lamented, Ahk site was striking. Now I'm pretty sure my computer was in bad condition.
- My Hero version continuously startups at ~60ms.
- O.k., your version needs ~1sec (now with new option for languages off), but after each consecutive startup it needs more and more and the whole computer becomes slower and slower. This shouldn't happen under no condition.
- Hopefully you can guess what's the problem!
- Otherwise I'll test older versions one after another, but only during the weekend. Can't afford it today, it's too time consuming.

Instructions for test:
- save all your work (you know this better then I do)
- run test scrip
- when MsgBox pops up hit Esc
- repeat several times (ten and more & more) and monitor time displayed

P.s.: Happy kitties! (The white ones have to be on top, they dissipate less heat!)
Attachments
Klavier hero Unicode MOD 1.3.2_R_test.zip
(9.55 KiB) Downloaded 85 times
User avatar
Drugwash
Posts: 850
Joined: 29 May 2014, 21:07
Location: Ploieşti, Romania
Contact:

Re: GUI: piano keyboard

04 May 2018, 03:58

If I did what you're asking the script would leak resources until the system choked. The OnExit call should've been included before the message box so that on exit all changes would be reset and all libraries would be unloaded.
This system where I'm developing and testing the script has an uptime of 5 weeks 5 days (measured by my Uptimer script), and the resources are at the levels seen in MemPanel at the top (the mauve one) in the screenshot.
20180504090708-crop.png
20180504090708-crop.png (30.5 KiB) Viewed 4200 times
If there were any major issues with the script, my resources would've been very low by now so I'm not sure what exactly makes your computer behave like that. Could be an x64-related issue or something else different between XP and your… Win10, if I'm not mistaken?

However, I admit there may be some problem with the sound. I did experience sound lag on the Duron machine with some previous version but chalked it up to a possibly bad implementation of the SiS730 chipset that drives that board. What I noticed was that switching MIDI devices (three in the list) would reset them and lag dissapeared.

On this machine I'm mostly working "deaf". The built-in AC97 device is connected to a loud pair of speakers whose usage I'm trying to avoid (could scare the cubs or their mother) and the bluetooth headphones require the usage of a third-party application and some fiddling around, plus the battery gets drained fairly quickly so I use them sparingly. Therefore I wasn't aware of any sound latency or lag on this machine.

My version takes some time at startup regardless of the visual hints (characters) being enabled or not because it still initializes the font and character lists required by OpenGL and also builds the preview window, should the user enable that option during the session. The Arial Unicode MS font is quite large (~23MB) and it takes time to load it and build those lists. On this system a full startup of the script takes about 4-5 seconds.
I could try to move all this initialization to the toggle subroutine, but it would still take the same amount of time on first enabling; it would however avoid any delay for users that never enable that feature.

Monitoring startup time may not be accurate since my system is low spec and any other application that requires high CPU time (browser, mail app popup etc) would affect the measurings.

Currently I'm looking through the code, already fixed a few minor bugs but nothing related to resource drain or sound lag.
I'd appreciate if you could explain as detailed as possible which version you consider the original, how you define keyboard responsiveness (time to display visual cue on key pressed, time until sound is issued, both, other?), how you define MIDI latency. That's just to make sure I don't misunderstand something.
Part of my AHK work can be found here.
User avatar
rommmcek
Posts: 1470
Joined: 15 Aug 2014, 15:18

Re: GUI: piano keyboard

04 May 2018, 07:40

- My last post has three paragraphs (w/o Post scriptum)
- Last sentence in first paragraph is just description of my meticulous observation. The differences are of minor importance, I think. Just for your info.
- Anyway, Midi latency is the time when the Midi command "NoteOn" has been fired and the time when the speaker actually sounds. So, very short NoteOn command (i.e. being very quickly followed by NoteOff command) may result with distorted or even no audible sound at all. This of course depends also of system, Midi Device, Cpu load etc.
- Keyboard responsiveness is a property of Virtual keyboard being able to react on very short key presses.

- I did this test on fresh restarted machine with no other app running (forgot to tell you, but you know it)
- I made it once again according to your recommendations. I think it's better but altogether the same story. Startup time rises on and on. This is not happening with my version (my _UR6, original _U - attached).
I could try to move all this initialization to the toggle subroutine, but it would still take the same amount of time on first enabling; it would however avoid any delay for users that never enable that feature.
- That would be great!
Attachments
Klavier hero Unicode MOD 1.3.2_R_test_2.zip
(15.05 KiB) Downloaded 74 times
User avatar
Drugwash
Posts: 850
Joined: 29 May 2014, 21:07
Location: Ploieşti, Romania
Contact:

Re: GUI: piano keyboard

04 May 2018, 09:28

I just tested R_test_2 from the attachment above for ~15 times, and load time actually decreased from ~3600 at first launch to ~2900-3000 on subsequent launches. Only once it raised to ~4000, but after a pause and relaunch it dropped to ~2300, then back to ~2900.
Memory usage (RAM and page file) after closing script returned to the values prior to launching it. I see nothing wrong here.
Have you checked the ini file for any anomalies?

Responsiveness seems lower in the v1.1 script (the one you call original) compared to latest one which is in the works. That one wouldn't even get to draw the pressed state of the keys when hit for a very short time; the latest does. I'm also testing mouse clicks which are as responsive as the keyboard.

If anyone else would like to test and provide feedback it would be most helpful, maybe I could find the cause of the problems. In the mean time I'll perform a few tests also on the Duron machine and maybe on Win7.
Part of my AHK work can be found here.
User avatar
rommmcek
Posts: 1470
Joined: 15 Aug 2014, 15:18

Re: GUI: piano keyboard

04 May 2018, 10:30

Just made test on win7. First start 2sec. All consecutive starts ~0.5sec. This is weird.
User avatar
Drugwash
Posts: 850
Joined: 29 May 2014, 21:07
Location: Ploieşti, Romania
Contact:

Re: GUI: piano keyboard

04 May 2018, 14:48

Maybe the OS caches certain libraries (at least for a period of time) to load them faster. Not sure about the Prefetcher, it may kick in too.
Don't rule out possible bugs in Win10, in my opinion that's not an OS to rely on. Additional software like antivirus may impact on performance too.

Please let me know if there's any improvement in this version:
Klavier hero MOD 1.3.3.7z
(13.64 KiB) Downloaded 91 times
v1.3.3:
- fixed a few bugs related to channel/instrument initialization
- reorganized part of the code for a quick start when hints are not enabled
- added nine drum kits known to M$ GS Wavetable SW Synth (make sure to use the updated ini file in the package !)
- added ability for "sweep effect" using the mouse (not perfect but usable)

There's a Debug switch, set it to 1, open a debugger (DbgView, WinDbg etc.) and launch the script, it'll show how long various OpenGL parts take to complete as well as total load time.

If anyone knows the correct name in musical jargon for what I called "sweep effect" please chime in so I could use the proper name for that option.
(drag mouse with left button down over keys left/right to get the effect)
Part of my AHK work can be found here.
User avatar
rommmcek
Posts: 1470
Joined: 15 Aug 2014, 15:18

Re: GUI: piano keyboard

04 May 2018, 15:27

- Tested 1.3.2 on XP. First run 3.5s, all consecutive runs ~1s.
- I was going to suggest glissando (you baptized it sweep). Midi works pretty good, while keyboard don't show all the keys if the "sweep" is fast (diminished responsiveness).
- I'll make the multiple run test only now (after posting this).

Edit: Tested 1.3.3 on Win10 (my test - not debug). First run 1s, all consecutive runs under 1s (0.5-0.9).
Looks very promising!
Edit2: Tested with "Show hints on keys" checked and the startup time went up. Occasionally I unchecked it and time was constant but elevated (OS was compromised, I guess). When I came to 10s (checked) the unchecked time was 2s.
User avatar
Drugwash
Posts: 850
Joined: 29 May 2014, 21:07
Location: Ploieşti, Romania
Contact:

Re: GUI: piano keyboard

05 May 2018, 01:21

Thank you for testing and feedback.
I have no idea what triggers such huge startup time under Win10. I put those debug commands specially for catching load time for each important subroutine. Total time is useless, your guess is as good as mine. Please do perform the test with the following Debug version, that should tell where exactly the load time increases, then we may try to pinpoint the exact commands/functions that trigger it. I do have a small hunch it could be the loading/unloading of all keyboard layouts known by the system but that's to be confirmed or denied by the debug output.
Klavier hero MOD 1.3.3.1 (Debug).7z
(13.85 KiB) Downloaded 75 times
v1.3.3.1:
- added more debug points and enabled Debug switch (use DbgView/WinDbg/etc to view debug info)
- changed effect name from 'sweep' to 'glissando' by rommmcek's suggestion

And here's the debug log for a few subsequent runs of this very same version on this XP machine, first with hints enabled and then without (check the log where it says UseHints=1 or UseHints=0).
Debug Klavier hero 2018 v1.3.3.1.7z
(2.06 KiB) Downloaded 93 times
A couple of extra questions:
1. Do you have the Arial Unicode MS font installed on the Win10 system?
2. Did you test applying several different layouts in the script, and if so do all characters look correctly on keys and in Preview window?
Part of my AHK work can be found here.
User avatar
rommmcek
Posts: 1470
Joined: 15 Aug 2014, 15:18

Re: GUI: piano keyboard

05 May 2018, 07:54

- I do have Arial Unicode MS Regular installed.
- I tried some different layouts and some (e.g. Japan) showed squares, but didn't test startup with them.
- Debug log: I started 10 times for each option (i.e. On, Off), then OS restart (had no other way).
Attachments
Klavier hero MOD 1.3.3.1 (Debug) Hints.zip
(7.83 KiB) Downloaded 80 times
User avatar
Drugwash
Posts: 850
Joined: 29 May 2014, 21:07
Location: Ploieşti, Romania
Contact:

Re: GUI: piano keyboard

05 May 2018, 10:57

Thank you.
Did you check if you still have all your layouts installed (in Control Panel) as usual or if new ones got installed?

Apparently LayoutList() takes more and more time on each startup, just like I thought. I'm afraid this is an OS issue.
What I'm doing in the script is load each layout, get its HKL and KLID, then unload it, but only if it's not in the installed layouts list. Maybe some layout(s) slip out of that list and remain installed, or get uninstalled erroneously, or for some reason they get duplicated. This does not happen on my XP.
Anybody else care to test under Vista/7/8.x, either x86 or x64, and report their findings?

For now it's best to leave hints disabled until further info becomes available. Sorry for all this trouble, just wanted to make it more user-friendly.
Part of my AHK work can be found here.
User avatar
rommmcek
Posts: 1470
Joined: 15 Aug 2014, 15:18

Re: GUI: piano keyboard

06 May 2018, 16:44

- just made fresh OS update
- didn't help for LayoutList() load time
- v1.3.3.1: glissano (works perfectly), even if I didn't noticed improved responsiveness (my report "midi works pretty good" was understatement it was and it is perfect)
- noticed a minor bug though: when leaving the keyboard with LButton down and release it outside, the key stays On
Attachments
AllKeysOn.gif
AllKeysOn.gif (51.12 KiB) Viewed 4200 times
User avatar
Drugwash
Posts: 850
Joined: 29 May 2014, 21:07
Location: Ploieşti, Romania
Contact:

Re: GUI: piano keyboard

07 May 2018, 01:37

Thank you.
There is a small change in 1.3.3.1 regarding glissando, I took out a Sleep in MouseMove() which restored the normal behavior. It was there in an attempt to mitigate certain unwanted notes that may get triggered when clicking and moving cursor too fast. You may have noticed that. However, the Sleep solution is not optimal.

The bug with keys stuck "down" has carried on since the original version by Bentschi. It happens because the window stops receiving mouse messages (in particular here WM_LBUTTONUP) when cursor is outside the window. I'm not sure how to fix that - haven't had much luck with TrackMouseEvent() and WM_MOUSELEAVE in other scripts, while a low level mouse hook may be overkill. Don't say "use a timer to check mouse coordinates". :) I'll keep it in mind though, maybe a good solution will present itself.

Yesterday I ran some tests on Win7 and confirmed the issue of startup time rising. At some point a new layout has been installed - or better said missed being unloaded; in the beginning there were 18, from some point on it started counting 19. There's also a raise in UpdateLayout, maybe more notable when switching layouts during the same session. One reason may be a continuous creation of character lists without deleting the previous ones. I believe the following should fix at least this issue:

Code: Select all

; add this If block before the lists generation
If (FontOut && FontIn)
	{
	DllCall(glDeleteLists, "UInt", FontOut, "UInt", charR)
	DllCall(glDeleteLists, "UInt", FontIn, "UInt", charR)
	}
; these already are in the script
FontOut := DllCall(glGenLists, "UInt", charR)
FontIn := DllCall(glGenLists, "UInt", charR)
Unfortunately there are more problems with character generation. A single font is not enough to cover all Unicode blocks, and automatic font substitution can't work in this situation; while I know how to check for supported Unicode ranges in a font, I don't know how to find out what Charset or Unicode ranges are required by a specific keyboard layout in order to search for an appropriate font. If anyone knows please chime in anytime.

Then I can't get a real CJK layout even in Preview, they all display standard English characters. There's a second section in the registry that deals with IME-enabled layouts and it probably has to be taken into account. So much work for only a few hints…

That's about it for now. Will keep checking for bugs, and looking for solutions to the problems. Any help would be appreciated.
Part of my AHK work can be found here.
User avatar
rommmcek
Posts: 1470
Joined: 15 Aug 2014, 15:18

Re: GUI: piano keyboard

07 May 2018, 08:17

- I wouldn't suggest timer, but was thinking about MouseGetPos (may not be used every cycle) and if there is wrong win underneath abort...
- If block for DeleteList seemed not to help
- I posted CJK issue on Chinese forum

P.s.: I think layout preview isn't indispensable, however it is a very fancy feature!
User avatar
Drugwash
Posts: 850
Joined: 29 May 2014, 21:07
Location: Ploieşti, Romania
Contact:

Re: GUI: piano keyboard

07 May 2018, 10:22

MouseGetPos must be triggered by something in order to get current position and verify against window handle. What could that something be, apart from what I mentioned in previous post?

That If block should've fixed only the growing time in UpdateLayout, nothing else. But maybe that's not the issue there.

The CJK layouts are a bit complicated, I believe the script should somehow signal that it's IME-ready or something of sorts. Or maybe the OS needs a real hardware CJK keyboard. That's kind of uncharted territory for me, and I definitely don't have a hardware CJK keyboard at hand to test with.
Thing is, not even OSK would display any CJK layout (either in XP or 7) regardless of the application that I set a such layout for (currently I only have Japanese installed). I do however get Arabic, Hebrew, Russian layouts in both OSK, Preview and keys window. I even get Divehi in the Preview window but not on keys because of the missing font substitution feature.

And on this note I'm getting annoyed again because the APIs that should solve this problem, don't. I've been struggling with WM_GETFONT+GetObject() and GetTextFace() to no avail, they all return the font set through GUI, Font or SelectObject(), or even a bogus System font - just not the actual substitute font, which is precisely what's needed to get things working. Dunno why simple things should be so complicated. At this point I'm afraid the only solution would/may be the use of Uniscribe, which I'm trying hard to avoid; it's been quite a while since I tackled that subject (in CueBanner) and forgot everything.

The Preview is there mostly for those situations where the user has no idea what language the hardware layout belongs to. Granted those situations may be rare but still possible, I myself got my IBM Model M keyboards years ago with unknown layouts - could be German, could be Dutch, could be Belgian or even Danish, Norwegian or something of that kind. In such case the user could loop through each software layout in the list until a perfect match is found, at which point the preview could get and remain hidden. There are also the non-latin layouts that would need perfectly matched visual cues, at least for beginners. And last reason would be uncommonly shaped keyboards that may have certain keys in different places or missing altogether; user could compare the physical layout against the Preview to find out if they miss any keys or if they are misplaced.
But yes,it's not indispensable - it's just nice to have it around. :-)
Part of my AHK work can be found here.

Return to “Ask for Help (v1)”

Who is online

Users browsing this forum: tiska and 107 guests