Is there any desktop wpm counter software out there?

[Harvey]

I worked for a transcription company that had its own web-based editor that would show you your wpm in realtime, and I noticed that my speed just got better after I started to write for them. I think having that for steno would be beneficial for me. Does anyone know any simple software that I can use to watch my wpm as I write/type? I just want a little window that shows my speed as I write, maybe up dating every 10 seconds or something like that.

Thanks!

[Paul Beaudet]

Harvey,

 I wrote something that would allow input into a text box in a html field and have a similar effect, but that's not what you're looking for I think. It's pretty easy to do in javascript.

 Doing it in realtime is not that hard, but it looks different from what you might expect. Unless the program figures when you've actually started and stopped you're averages are going to be way off. It wouldn't be too hard for me to write but I would rather see if someone else did it though because I have little experience building something that directly grabs x events from the os like Plover does. 

What os are you using?

[Harvey]

I'm using Windows 10. The idea I have is that it only starts counting wpm while you're typing, and only shows it for the last 10 seconds. I'm not really interested in averages or statistics that much. I just want to see my wpm at the moment so that I can get a feeling of instant gratification.

I'm not asking you to write it for me as I think that would be a lot of work just for one person to use. Thanks for the interest though.

[Paul Beaudet]

 I'm actually mostly interested for my own selfish purposes. Global input speed rec could be useful to research I'm doing on various input systems . Would think this is something that someone has already built though. Already programed something like this for my Arduino Yun keyboard converter / logger, but I don't use it much, not compatible with Plover and that stupid Yun takes 90 seconds to boot. (whereas I used to having immediate access to my keyboard when I plug it in )

[Theodore Morin]

Brent's training tools had a WPM ticker for Plover at some point. You might be able to find a build by searching for "training tools" in the group.

--
You received this message because you are subscribed to the Google Groups "Plover" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ploversteno...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Paul Beaudet]

Ok I found the source here -> https://github.com/brentn/plover

There is a branch titled speed_report I sure the diffs there will be enlightening. This fork is way too far behind master for me to want to use it, particularly when updating to the latest version has fixed a few issues I was having (garbage strokes and return sending 10 instead of 13 apparently the url bar cares).

Looking around in Plover configure I just discovered the stroke display. Ted, would it be in the spirit of the project to have a WPM counter under the "style" element or is this scope creep? Or may be separate performance display accessed in the display tab of configuration? The strokes and actual words per minute would help me more than the poorly defined 5 char WPM standard, though obviously WPM would be the most important to most people. Along with average word transit times. First PR would be only real time WPM, not really what harvey is looking for but it's an easier place to start, I tend to micro commit stuff.

Now, I'm not going to get to this right away maybe not at all depending on how the code is set-up or what comes up on my agenda. Going to take some time just to understand the existing structure and style, I have yet to look at it too deeply. Just read through some of the code last year, because I had a related idea making a shorthand system for Tenkey. 

A speed tracker is something that would be valuable to have for learners, without tracking progress through typing test it's hard to know how much practice one needs to put it to reach their goals with steno.

Am curious why Brent's commits are still only part of his fork, no comment necessary though. I do understand if we are trying to stick to the Unix principle of do one thing well with Plover.

[Theodore Morin]

I'm totally onboard with the idea of the WPM ticker, I only haven't worked on Brent's implementation because it's not running at all on my system. The PR is still open and needs some work. If you'd like, you can start off Brent's work or start fresh. He also had some other training tools which were interesting. There's also the stroke suggestions in the current branch which may be a duplication of some of the training tools functionality.

I'd say that the WPM ticker could have interesting statistics... real time, averages, stroke speed, keys stroked for minute, and more. I'm very open to your development.

If there's one thing I'd request, it's decoupling from the GUI. Make a service that a GUI can display, but don't make them one and the same. If we ever move away from wx, I'd like it to be as painless as possible. If you have any questions feel free to ask, and you can open up GitHub issues at will and we'll sort accordingly.

[Paul Beaudet]

 okay, so I took some time to look at the source. Comments are sparse depending on where you're looking, its tough to see the forest through the trees. Variables are named well for the most part though  and the organization is sensible, so its not that hard to follow what's going on. Definitely seeing the friction with WX. The only time I messed around with gui was pytkinter. So its not like I have much to compare to. Just remember it being less rigid/explicit than WX.

 Your request resonated with me until I looked at the code. Seems like modularity would be a new direction on the GUI level. Looking at paper_tape.py I really can't tell in from out. There are less than 5 comments in 280 lines of code. Most of the code seems to wrangling WX to behave as expected. Which is impressive. Okay, well I guess your request still resonates.

Direction on grabbing strokes would be helpful.

Maybe I'll just write results to STOUT for testing purposes. I don't think the performance service logic will be as difficult as getting the interface to do what we want it to do. In fact I have much of it written from the TK project I mentioned.  

[Theodore Morin]

Paul, I've been planning to create a class diagram to break down the relationship for files, I can move that to the top of my priority list because it was short term stuff anyways. It'll help me, too, because it's not always intuitive!

Yeah, the code tends to be "comment-light", but in most cases it's because it's pretty simple stuff. If you find code that really needs comments, just submit an issue on GitHub and we can address it.

[Paul Beaudet]

" in most cases it's because it's pretty simple stuff "

I had an optical engineer basically tell me that the other day about making Holograms. " Ya know just inverse the refracted light from the flux cap source, its pretty simple stuff "

He did say it so nonchalantly, almost thought I missed elementary school or something.

My coded tends to be comment heavy, inline (aka completely unreadable without syntax highlighting), is there preference against? 

BTW sorry Harvey, this got away from the OP... kinda. I really want a wpm speedo

[Theodore Morin]

Yeah I'm not huge on inline comments except for things that aren't intuitive. The git history tends to be pretty rich though.