If/when/how you want to change anything about the file chooser is up to you. Obviously I can always open a file with Deflemask after some minor difficulty-- but its current state is a thing that has consistently frustrated me (and others) when trying to use the program. Some additional suggestions about how to improve it:
- I actually think the easiest and best solution to the file chooser issues is to use a native file chooser instead of recreating your own from scratch. Yes there will need to be 3 implementations, but a native file chooser is generally only a few lines of code per platform. Every user already knows how to use their native file chooser and will not find it frustrating.
- If you do need to continue with the one you have, I notice you already seem to have a .. in your file chooser for navigating up, but it is suppressed on the songs/modules/[system]/ folder. Allowing it there and above would immediately free the user from being locked to those specific folders. Even better would be to save the last used directory and start from there. I'd also suggest that you make the default the songs/modules/ folder, since opening a file should have nothing to do with the currently selected system. (Also, saving the MRU folder would leave the user in the last system folder they used anyway, which would retain that behaviour for people who still want it.)
- Drag and drop was tried because issue #1 gave no feedback when it failed to open the file, and issue #3 made it impossible to try to open the file without hunting for DefleMask and transferring the file into its songs/modules/genesis/ folder. Yes it is not the easiest thing to implement, but I thought it was worth suggesting.
On another note, I have discovered the source of the framerate issue by comparing with a different config.ini. It doesn't appear to have anything to do with max_fps. The framerate drops dramatically when buffer_size = 3, which is the setting in Chip Champion's zip. The older config.ini had buffer_size = 1, and with this setting it refreshes at the expected high framerate.
Now that I know it has to do with buffer size, playing with it in the options menu I can see this effect immediately. I would presume that Deflemask updates its gui only when buffers are swapped? When using buffer size of 8k (buffer_size=3), would I be correct in guessing that the framerate is exactly: 44100 / 8192 = ~5.4 fps?
Kind of interesting is in the FAQ there is a question about how to improve performance, and the suggestion there is to increase the buffer size. If the problem is visual performance, this actually has the opposite effect. Maybe you should revise this FAQ suggestion to be like this:
* Q. Deflemask has stuttering audio, or choppy visual performance. How do I improve this?
* A. If the audio is cutting out, try increasing the buffer size in the options menu to give your CPU more time to process the audio, or decrease max_fps in the options menu to reduce the rate of visual updates. Poor visual performance is solved in the opposite way; decrease the buffer size to achieve faster visual response times.
It is possible to update the UI in between buffer updates, but it may or may not be a complicated thing to implement (since it's closed source I can't speculate too much-- probably the easiest thing is to use a partial buffer for each frame update and stop updating if the end of the current buffer is reached but a new one is not ready yet). Personally, it runs fine with smaller buffer for me, so this is not a problem now that I know what setting is causing it.
Though one thing I would ask is if the visual update is tied directly to the buffer size, max_fps seems like a useless setting. Is it posting updates at the max_fps rate even though there is no new information until the next buffer?
