OK, I'm a little late - at least, I'm planning to have a new patch considering Phil's major points ready for tomorrow...
On Friday 19 September 2008, Stephen Warren wrote: > If I press and hold the button on the original remote forever (I tested > 60 seconds), the recording process takes forever. I guess perhaps it'll > automatically stop if some maximum pulse limit is reached, but this can Matter of fact, so far it doesn't - it will keep on reading data from the remote until forever if you don't stop pressing a button, and just stop writing to the buffer if it's full. I have now added a check for both a maximum duration (I've made that 5 sec for a start) and the buffer being filled. I should probably return some LC_ERROR_OVERFLOW for these cases in a future version. > * Provide the learned signal back to the client app in chunks, and let > the client app keep calling "learn" if it wants more. The API would > probably need to be "setup for learning", "learn a chunk", "stop > learning", or something like that. Would need some more work to determine a proper termination of such a 'chunk' - maybe some reasonable space in the signal? Who would decide on the client side whether enough chunks are received? Probably not the user - he's already busy pressing keys, and the learnig will currently stop anyway if he stops pressing for more than 500 msec. > * Analyze the signal, and determine when the initial code and "enough" > repeats have been seen, then stop. Maybe too limiting for users who want to have more than "enough" repeats learned for a raw code for some special purpose - quite a few even like to learn sequences of several keys as on single raw code; we shouldn't forbid that. > * Assume the maximum time to wait for the user to press the original key > is 5 seconds, and the maximum learning time is 2 seconds. > Whilst no IR has been received, move the progress bar between 0 and 5/7 > of 100%, based on elapsed time since learning was initiated. The 5 seconds is currently a single timeout for the HID reading call; this would have to be chamged to a loop with n iterations over reads with 5/n seconds timeout and progress callbacks. > As soon as some IR is seen, jump to 5/7 of 100% > > Whilst IR learning is in progress, move the progress bar smoothly > between 5/7 of 100% and 100%, based on elapsed time since the first > piece of the IR signal was received. (possibly for this phase, take the > max of % max time elapsed, and % max IR signal buffer size filled.) May be possible, but some more guessing required to avoid to many interruption of the signal processing by progress callbacks. Could use the new calculated total time to send callbacks every ~500msec. > I would be OK doing mapping of callback information to percentages in > the client app, but since there's no feedback of any kind from learning > (no "seen first bit of IR" callback, or "asynchronous abort IR learning" > functions, or defines exposing time/size limits on the phases), I can't. You currently just cannot abort the initial timeout until an IR signal is received, because that's completely encapsulated in the HID module. Once started receiving, the user can always abort by just releasing the pressed remote key, stopping the IR signal. I will hopefully find some time to check this callback stuff in the next 1-2 weeks. Andreas ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ concordance-devel mailing list concordance-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/concordance-devel
