I want to make one last attempt to communicate the importance and benefit of these changes before giving up. Maybe I haven't explained it well enough.
Communication requires more than just a speaker and a listener. To be effective and reliable, the listener must acknowledge that he has received the message from the speaker. This applies to human communication as well as computer communication. So first I will state what I understand you to be saying here.
1. You believe completely that "The key functions should manipulate key state, period." You know this to be absolutely correct, and you will not consider any evidence to the contrary. Thus, no changes to the key functions will ever be implemented, period. Even if I make changes, test them, show that they work, and demonstrate that they significantly improve the function of the camera, you will not read them, you will not test them, you will not implement them, period.
2. Even if these changes work and significantly improve the performance of one camera, there is a possibility that they might not work on other cameras. Even if I eliminate the possibility that they won't work on other cameras in all known ways (video mode, no NR hook), there are still unknown cameras out there that might not work. This would be a catastrophe so severe, that it is not even worth taking the risk of trying even a limited test of these changes. The world might end, and we would all die. Don't even look at the changes or God forbid, try them on your camera, or you could die.
3. Even if my solution solves the shooting problems with a few lines of C code, works faster and reliably, and greatly simplifies writing and learning to write scripts, you will not implement them. There is a way to work around these problems by using multiple ubasic and lua script delay loops that you believe is superior to the proposed changes, and you will not consider evidence to the contrary. The fact that this makes script programming much harder to understand and learn, as well as scripts much harder to get to work is irrelevant to you. You believe that doing this in a script is superior, period.
Please don't be offending by the satire. I'm just trying to make it as clear as possible how I interpret what you're saying; that is, acknowledge what you have communicated to me, not just what you have said. Here's my response:
1. The key functions are not just a manipulation of the key state. Their fundamental purpose is to communicate with a different thread (task), so that thread will start a new action. They are implemented as actions so they can manipulate the key state, and hold that state until the other thread receives it.
The key functions are currently implemented unreliably. After changing the key state, they wait a fixed amount of time hoping that the other thread will notice the new state. I call this "delay and pray." This method is fundamentally flawed. Communication with a different thread requires acknowledgement from the other thread that it has received the message.
My modifications are a simple way to get an acknowledgement that the other thread has received the message. I have tested them, and they have worked every time. When my test scripts do click("shoot_full_only"), it works every time, period. You can't argue with success (maybe I should re-examine this belief?) This should also be done with shoot_full, but I removed that part for testing because of your concerns, even though I disagree with you. But you still won't consider testing the code, even on your own camera.
2. The possibility that a change like this won't work on some cameras is real concern. But right now, the key functions don't work reliably on ALL cameras. When a problem occurs, like the phantom "shoot()" bug, it's very difficult to figure out what happened. "Delay and pray" works most of the time. But it introduces subtle bugs that are impossible to reproduce. These are the worst kind.
All of the concerns expressed here involve a bug that hangs the camera every time. These changes should work all the time, or never. These are the best bugs to figure out and fix. CHDK is set up for this purpose, with updates daily to fix bugs. If cameras or scripts show up that don't work, together we can figure out the problem and probably have a fix by the next day. If my changes hang a camera, the user presses the shutter to abort the script. The changes don't effect the camera if a script isn't running. For debugging, if my changes hung the script, I can print the message, "Lapser is an idiot", along with the "Interrupted"message.
3. Using script functions to wait for an acknowledgement from a different thread has real problems. Scripts are not reliable for real time operations. They are slow, and can be interrupted at any time, for several seconds even. The camera could finish the shot and return to its resting state without the script ever noticing. More importantly, it is important to hold the shoot_full or shoot_full_only keys DOWN until receiving the acknowledgement. The only way to do this for the "click" function is to wait for acknowledgement before returning. It can't be done in Lua, so "click" will never work. My changes make "click" work reliably (tested and proven).
CHDK scripts run in the keyboard thread. The keyboard thread also reads the key presses generated by the key functions. The script has to be interrupted repeatedly for the key presses to be recognized. You're also asking the script to monitor the state of the camera to look for an acknowledgement that a key action has been received, but which won't be received unless the script is interrupted often enough. The complexity and inefficiency of this is mind boggling.
What's more, I've implemented this script-based scheme in my time lapse modifications and it doesn't work correctly. The script randomly delays pictures for seconds at a time before it finally recognizes the signal from my C code, and signals back that it's OK to shoot the next picture. If you try to shoot faster than about 2 shots per second, the shots are no longer regular. Attempts at 1 shot per second vary from 1 to 3 seconds between shots.
A few simple modifications to the press, release, and click functions for shoot_full and shoot_full_only would fix all this, yet you refuse to even try it. That's why I labeled this post,
"Missed Opportunity"
