Yet more good news on the hardware front, courtesy of Gotta Be Mobile. Software will quickly be the only hurdle left. I'd better get to it, and quick -- only two years until this baby gets released!

I've set my eclips timer to zero. As you can see, that means it can
only translate one-sillable words correctly, but it's useless for
anything that takes more than one stroke. But that's okay, because
I'm using it to break up a script in vim, so I don't
really need to write anything in the way of words. It's slow going
for the time being, because I don't have the commands bred into my
finkers properly yet, but I ants pate that it'll feel pretty natural
after I've been at this for a few hours. When I said one sillable, I
meant one-stroke. But I think I'll let this stand as a testment to
the pointlessness of timers. If I increased the lag, all my words
would translate properly, but I'd be unable to edit effectively. This
way I can't use my steno machine for writing, but at least I can use
it for editing. I'll get the victim commands set in my finkers --
that should be vim commands, obviously -- and then later, down the
road, once moreover is working -- ha! And that should be moreover.
Plover! Mover. That's hill airious. All this thinking and planning,
and I haven't even gotten around to putting the word Plover in my
dictionary yet. That was finker spelled. I'll have to recollectify
this. Oh, lordy. What an embrassment. I hate timers. Hate them,
hate them, hate them. All right, enough examples of mistranslates.
I'll get back to training my finkers into using vim on the steno
machine.

With respect to that last entry, there's also capitalization and hyphenation to consider. If I write "one of a kind" and then stroke HAO*IPB three times, how smooth is the redraw? How do we make Plover understand that it needs to hyphenate backwards, skipping words that are already hyphenated? So with each stroke we get "one of a-kind", "one of-a-kind", et cetera, until it's full up. The response needs to be quick and natural. Most people don't count how many words they want to hyphenate; they just stroke the command until things look right.

The problem with Plover being first and foremost a keyboard emulator is that steno revisions are frequent and necessary. An example: SRAEUG, by itself, will be rendered "vague". But if you then type "REU", it needs to turn into "vagary". And then if you add "S", it needs to turn into "vagaries". The natural solution is to send backspaces before sending the new letters. But do you backspace the whole word, or do you determine how much you need to change? And if you do the whole word, will it be intrusive? Sometimes you need to delete 10 or more letters for a single stroke. How quickly will that be done? Will the rollback be annoyingly slow or make it feel like there's a slow response time, or is there a way of making it instantaneous? Another alternative would be to use Ctrl-Z or Shift-Back Arrow/Delete, but those aren't foolproof ways of deleting previous words in all programs; they're soft conventions. The other steno programs solve this problem by keeping words in the buffer, but I hate that, because when you do want something displayed instantaneously, it means you have to flush the buffer manually, which gets incredibly tiresome. I'll just have to see how the backspacing idea works out. Possibly we can incorporate options for word deletion that can be customized to particular programs.

I haven't cracked the book in ages (been reading pulpy novels instead), and I was gonna go to the next NYC Python meetup, but it's on the same night as my ASL class. I've still been thinking constantly about Plover, but to no real end; I feel like the project has stalled. I wish I could find a programming buddy to get together with. I corresponded a bit with someone who was advertising for a Python tutor on Craigslist and said she'd pass him along if he wound up being any good. Haven't heard from her in a while, though, and I'm not sure I could afford a tutor. My brother's been good as gold, corresponding with helpful ideas and novice projects over the internet, but it's hard to put the time aside when you don't have to answer to a physical face. I've also been struggling to make as much money as possible with my freelancing gig, which has run up against my slackier impulses. Diligent, incremental independent work has always been my weakness, and it's the one thing I need to instill in myself before I die. I want this program, both to use myself and to distribute to people who could get a hell of a lot out of it. I want to learn how to program, for the geek cred and for its own sake. I need to freaking get started.

Idea for Gemini's extra buttons: one alt, one ctrl!

And this is even better. Come on, future! Get here already!

This is potentially fantastic news. If Microsoft is really serious about promoting touch interfaces and puts enough money into the concept to make it a genuine phenomenon, we could be obviating the whole hardware problem in just a few years. As I've said before, the biggest issue with promoting steno to geeks is the price. Geeks like to play around with stuff before they commit to it, and when you're talking $5,000 steno machines (huge, heavy, and ugly as sin into the bargain) plus $4,000 software, there's just no way you're going to attract anyone who hasn't already determined to singlemindedly build their career around it. There aren't many instantaneous fanatics like me, nor should there be. I want steno to be primarily an auxiliary system to facilitate high speed composition (of text and code), communication, and portable computing. Writing and distributing Plover freely will, with luck, take care of the software issue. Cheap computers with built-in touch interfaces will eliminate the hardware shortage. Add haptic feedback (which should come in the next generation of widespread touch interfaces) and ultra-portability and you're gazing at my bright utopian stenofuture right there.

I found Learning Python! I thought maybe it had dropped out of my jacket pocket or been left somewhere, but it's been buried in the bottom of my closet this whole time. I've been a dreadful slacker with this blog, but I hope once I can find some relatively steady work for the summer (which is where most of my directed energy has been going) I'll be able to get back to Plover with a clear conscience.

Plover must take arguments in its command line. It's very frustrating not to be able to enter "eclipse 0416ap.ecl -mz_edit" or something like that and have the program open up the file of my choice, applying the settings of my choice, all in one step. Instead I have to open Eclipse, then select the user settings I want, and then open the file manually from the menu. Frequently the last-used file in a particular user folder isn't even on my most recent files list, since all my students' classes are aggregated together.

Yet another Eclipse bug:



I suppose it's conceivable that this one might be attributed to human error, though if it is, I need to find what the error is so I can never make it again. Am I inadvertently turning stitching on? What the hell's going on? It's happened twice, and as far as I can tell all I've done to cause it is use the "?" key (set to "Find above - RT" in Hyperkeys) to find a word earlier in the document while my steno machine is still realtiming. This is what happens, and the only cure I've found is to stop translation and start another one in a new file. Seriously not cool.

Another baffling Eclipse bug:



The text was intended to be in all caps, but when I started writing, it came out mixed case. So I closed the file and started a new one. Now, going back to the transcript of the original file, I find that it appears to be mixed case initially (top picture), but as soon as I press page down, it transforms into all caps (bottom picture). Page up, and it's mixed case again. What in the flurgh?

A wacky bug in Eclipse:



As far as I can figure out, I defined -FP as {FLUSH}, and so every time I tried to write FPLT and it came out FP (as it often does), instead of a period, I got what appeared to be dead space. The first line is what it looked like on screen; the last line is what I originally intended. But the middle line is what I got when I positioned my cursor after the word "tidbits" and pressed "." to insert a period. Now, how the hell did that happen? And what does it mean for Plover, if anything? Something to consider. I've now defined -FP as {.}, so here's hoping that'll solve the problem.

It's ridiculous that Eclipse prevents multiple occurrences, and that I'm not able to have different user settings apply to different opened files. So I'm unable to set Eclipse running, start a job with the user settings of the student's next class, and then open another file up with another student's settings so that I can get some transcript editing done without having to worry that the class will start and catch me unprepared to start writing immediately.

I NEED A QUARANTINE FUNCTION, ARRGH!

Could I write a plug-in module as a sort of precursor to Plover, to plug into Eclipse? I might try. It's maddening not having one.

It's all getting more complicated. But, to be fair, more interesting. Back when I've got actual content.

Proper toggle; going to to gonna after the fact.

Have I mentioned Eclipse's jumping bug? I may have. I don't remember. For some reason, it clears the screen whenever a) you're writing in the lower half of the screen, b) you just changed speaker attributions, and c) the first thing the new speaker says starts with a number. Bloody, bloody annoying. And what on earth could be causing it?

So as soon as I got to the beginning of the flow control section of Learning Python, I was all "I can do this! Just let me start writing some code already." And of course now I've got all my elements in place but I'm driving myself nuts trying to work out the flow control, which is not cooperating. Should I give up and go back to the book? But this brick wall is so cuddly on my brainpan!

*BONK* *BONK* *BONK*

Using Python in Vim. I've been using IDLE so far, just because it's simple and familiar, but when I get around to it I'll definitely tweak my vimrc to turn on syntax highlighting when I'm editing .py files and all that.

The due date for ISWC papers is the 21st. I was considering hacking together a purely conceptual paper to send to them, but I think it'll have a lot more weight if I wait a year and can incorporate some actual demos of Plover in (fingers crossed) action. I wonder how rapidly cheap programmable touchscreen technology will develop. I'd love to think that my retractable gauntlet idea is not so very far away. I just checked back to this thread and realized I never actually described my brilliant gauntlet idea. How could this be? It's much better than gloves or bicep keyboards or hoody-belly keyboards with dangling hoody hood screen (adorably monkish as that might be). The gauntlets are just sheaths for flexible touchpads with tactile feedback that extend outwards when unlatched (preferably by means of some cool-looking gesture) to just beneath the the fingers in their relaxed state. A slight convex bend might be nice. I wish I could draw; it's very simple and elegant as I imagine it. You do your data entry and then stow the touchpads back into the gauntlets until needed. They don't get in the way of anything, and should be light enough that you barely notice them while stowed. Man, I want a pair of these things so bad.

I've determined the first task Plover needs to fulfill.

Given a dictionary with four entries, {KA-T: cat, HR-OG: log, KA-T HR-OG: catalogue, HR-OG KA-T: Log Cat}, produce the following input/output results:

>>> KA-T
cat
>>> HR-OG
catalogue
>>> KA-T
catalogue cat
>>> HR-OG
catalogue catalogue
>>> HR-OG
catalogue catalogue log
>>> KA-T
catalogue catalogue Log Cat
>>> HR-OG
catalogue catalogue Log Cat log

(Log Cat is Log)

What to do about the Gemini's extra keys? Obviously we're gonna run a Gemini protocol emulator first, because it's the only machine I have access to, the company is friendly, and it's the cheapest currently available machine on the market (not counting the $795 Treal, I suppose, but it seems to be of limited virtue.) Do I want to be able to set left asterisk to quarantine and right asterisk to delete? What about the Extra keys? I seem mostly to be hitting them accidentally. Do we want to allow the option of inserting the automatic space before each new stroke or after each old stroke? How do we make steno output compatible with qwerty-style typing tests?

And sometimes you just feel like this.

I need to identify both the ways in which Plover clones the features of mainstream CAT software and the ways in which it fundamentally diverges from it. I'll try to pinpoint them and post them once they're in some sort of coherent shape.

If we truly want both steno-stroke memory and complete qwerty-style keyboard emulation, we'll have to take mouse clicks and other arbitrary jump tools into account. As long as navigation is accomplished by either steno or keyboard commands (whether with the arrow keys, j/k, or whatever), we can calculate the position of the cursor and whatever it's next to, and determine by that whether we're at the beginning of a sentence and should capitalize the first word, for instance. But what about jumps precipitated by searching or scanning? What about mouse clicks? It seems like a constant reckoning of "where are we, and what was entered into the location immediately previous to us, irrespective of when?" might be more practical than trying to do the math in a linear sequence. But how much will that slow us down? What about jumping between windows? If one window has a period at location [X] and we enter a new word into location [X+1] in another window, do we have to worry about it being capitalized? Not if we're careful, I think, but it could get complicated. Do all programs even have the capability to tell us where our cursor is? I'm thinking not; certainly not without translating formats. Can we do it by reading the lines/bytes in the file? But what about white space and other invisible markers that might throw us off? This is a puzzle.

Not much brewing; going through the book and digesting it all at a moderate rate. The most commonly recurring question in my brain seems to be: will the Plover steno dictionary format be comprised of actual Python dictionaries, with the steno strokes as keys and the definitions as values? Or will it need to be more complex, somehow? Will it be quick enough? Things to look into.

The other thing to consider is the timer. Eclipse doesn't work without it. DigitalCAT has an option to set the timer to zero, but it causes a lot of bugs, including improper stroke deletion and affixion. I can't stand the timer. Plover needs to process each stroke as quickly as possible, relate it to previous strokes (if applicable), and put it on the screen without delay. Then if the next stroke, combined with the previous, translates to something else, it should cleanly erase the old translation and display the new one. There should be no timer involved. I suppose this necessitates a buffer of at least 10 strokes (unlikely that any more than that would be linked together, though who knows; maybe a user-editable feature) to be held in memory. Each new stroke would prompt a reassessment of all 10, and the screen would be redrawn accordingly. This is the only way to make effective editing and CART display practical. But why have none of the other steno programs I've used been designed that way? Is it simply a legacy issue, or are there other obstructions? I hate having to flush Eclipse's buffer manually every few strokes. It's absurd.

Clearly the biggest problem with the split system is that of defining untranslates in situ. That's the top priority. It can probably be kludged to work in generic text editors, but I'm worried that it'll have the potential to get pretty ugly -- especially if we're jumping around the document and Plover has no way of seeing where we are with respect to what's on the text editor's screen. Also, setting * to delete last stroke (an indefinite number of times) is tricky unless you have a way of accessing previous strokes. I'll have to think on this.

I was thinking about it last night before falling asleep, and the more I ponder it, the more it makes sense: Plover itself should be only a translation/dictionary management engine, whose native state is as a draggable status bar with optional invisibility, which can spawn dictionary windows at command, but is otherwise extremely unobtrusive. Every command should be keyboard controlled, with a few optional dialogue boxes for those in need of hand holding.
User editable ini settings, with output options of 1) steno stroke echoed in section of status bar as written, but not stored; translation output to keyboard emulator, 2) steno stroke output to keyboard emulator along with translation in the form of markup, which can be visible or invisible according to the view settings of a yet-to-be-written text editor plugin (Stim at first, though it would be great if this could gain wide acceptance, like HTML), 3) steno strokes output invisibly to user specified file, translation output to keyboard emulator. Realtime linking of the two might be too complicated, but we'll see. Everything relating to translation should be coded into Plover. Everything relating to steno-specific editing should be coded into Stim, which will be a lower priority Vim plugin to aid in steno document composition and CART work.

I've been pretty good about brain dumping to this thing. Not much new this session, except that I should mention I'm 132 pages into Learning Python and really enjoying it. So far it's been review, but he's filled in a few gaps that confused me in the other tutorials I'd read. I'm looking forward to getting into the advanced portions, and after that I hope I'll be ready for Text Processing

Eclipse's problem with capitalization after a moich or a kpa -- it must be reading the invisible command and capitalizing it, rather than the actual first word in the sentence next to it. Then there's some sort of bot that passes through the page and corrects it a few seconds later. Weird kludge. Find a better method.

First step: steno emulator so I can start work on the project before getting the hardware drivers working?

William is concerned about speed of processing. I know 160,000+ plus entries in a dictionary is considerable, but even primitive steno software in the 80s was able to handle ~60,000 without blarfing. There must be a way to optimize it. Obviously guessing algorithms are trickier and will take still more speed, but we're not talking fancy graphics here. I will have to think of some way to obtain the numbers; my guess is modern computers won't balk at the sort of simple text searching functions we need, even if they're implemented in a high level language like Python. I just need to confirm that guess.

Scan for fingerspelled words.

Transcribed from Moleskine:

1. Spits out raw steno when hooked up to Gemini. Not vertically, but left to right to fit screen, delineated by spaces. [I've changed my mind on this, and now think it should simply be |STENO| corresponding phrase, alternating next to each other, and made invisible or visible depending on what's used to view it -- like HTML markup.

2. Interfaces with simple lexicon (pref. rtf/cre) to translate strokes. Option of interlinear display with space between English words expanded to accommodate steno [again, I think this is misguided, because it further restricts steno output to Plover as a display/editing program rather than a translating-and-piping program], displayed centered below them. Toggle display of only steno, only English, and interlinear. No timer; provisional display appears immediately [with no confusing syntax designators like Eclipse has; option of toggling syntax in status window] and is replaced as new strokes alter the definition.

3. Editing, display customization, and keyboard emulation [I'm worried that keyboard emulation may have to be a more integral step; possibly the first thing through which everything is routed. Otherwise you might get the imperfect emulation of other steno programs]. Raw steno
can be piped to external applications as if by keyboard, as can translated steno. Separate command mode, or integrated?
4. How much Vim integration, and at what stage? [Should Plover be in two parts? One that loads on startup, like a keyboard driver, and allows for instant stenoing into any program with default dictionary settings, and limited options? And one that is more of an editing program, that allows customization and definition and all of that? Very hard to see where the line should be drawn. What it comes down to is that I want my steno keyboard to do everything my regular keyboard can do, with a minimum of fuss, but not giving up dictionary customization, and I want to be able to use Vim as easily as I do now with the regular keyboard. Maybe it means an invisible Plover background application and a Vim plug-in for steno-specific editing features.]


5. Guessing algorithms, metadictionary, etc. Plugins such as Typestriker, Bozzy, IRC. [Until we are able to duplicate Translation Magic, Plover, for all its virtues, will not be as practical as Eclipse, for all its flaws. High priority -- but, I fear, very complex.]

6. Optional status bar with stored (even after panic key) provisional definitions [this was what I was sketching out in the previous post], quarantine [unique among steno programs, as far as I know], one-stroke regex search. No dialogue boxes ever. [that might be a little extreme, but they're pretty damn annoying. Try to restrict everything to status bar, with silencing option]. Mouse support only a training wheel afterthought [Again, tone it down a little. A steno mouse emulator would be damn cool, especially for wearable applications. Might work, though -- one key of right bank, move mouse a little right, two keys, a little further, three keys further still, etc. I'd like to try it out.]

Invisible text (different levels of invisibility?), ability to write to file, suspend and resume definitions, taskbar.

Expand later when there's time.

Eclipse's Alt-R function (in the global window), which takes you to a dictionary entry and allows you to delete it from any of the dictionaries in which it appears, is invaluable. Duplicate it.

I've loaded the entry page as one of my home tabs, so I'm just going to use it as a brain dump for a while, until I've accumulated something worthwhile.

Eclipse bug: jumps to top of screen when new Speaker dialogue starts with a number. What could be causing this?

S + any entry in dictionary + S/Z (single stroke):

If it equals any entry in the dictionary: as written.
If it equals any entry in the dictionary that begins with S: as written, plus -s/-es. (If S,G,Z rule is on)
If it doesn't equal any entry in dictionary, but does when you strip S- and -S/Z off, translate as: "As [entry] as".

Text Processing in Python

The book came yesterday. I've been reading through the Appendix -- a review of Python. It's very well written; apparently the guy used to be a Humanities professor. I've gotten over my block with lambda and tuples and now understand them well enough. Classes, however, still stymie me. I'll keep working at it.

Link for my reference:

http://gnosis.cx/TPiP/

Arduino

Arduino is an open source language and hardware system. Might be very good to work with when building my own machine; certainly more practical than Flash. Not ideal for wearable use, perhaps, but I'll have to look into it. Might want to invest in classes at LEMUR, though the price is a bit steep. Probably should get Plover working first; this is a sidetrack. Still, something to file away.

I've got 15 minutes before I have to meet my boss. I should be doing Sheba edits, but instead I'm going to provisionally list the things I want most in a steno program that I'm not already getting in Eclipse. Many of these I already mentioned in the post on my regular blog, but I want to go into more detail on this one, and I figure a broad set of desired features (off the top of my head, with many more to come) will lay the foundation.

Back later. Okay:

General lack of dialogue boxes. Most crucial to this is search. Vim style searching with type-ahead find, forwards or backwards + wrap, with options to set ignore case or not = absolutely ideal. The current Eclipse implementation is a nightmare.

Options in DigitalCAT that aren't in Eclipse: anti-Gollum (auto in DC; should be toggle in Plover) setting, so that you don't get thingses like improper pluralses. Globaling of y to ies through the document when one word is edited (though case is not recognized in DC, so if you're doing all caps, you get CITY -> CITies.), -L,-G,-S,-Z auto translation. Possibly include -R as well. Crucial, crucial feature.

Edited 03/24: I'm choosing to post this rather than keep the draft to build on, because it just doesn't seem to happen. Accretion, that's the key. Little posts with morsels of information apiece. They don't all have to be treatises.

Brain Dump

I decided to make a separate blog for thoughts on Plover, since so much of what I've been turning over in my head is too technical and obsessed with minutiae to be of interest to readers of my regular blog. I'm uncertain whether I'll share this address with anyone else; if I get some good stuff down and can figure out how to refine my ideas, I'll probably pass it along to my brother William at the very least, since he's signed on to help me out with the project. Along with posts on the design of the program itself, I might use this blog to hold links to information on Python for beginners (which I surely am; Bozzy was about as simple as a program can be, and Plover will be more complex by many orders of magnitude.), or possibly idle thoughts about how best to disseminate steno throughout the hacker/wearable subculture. Here's hoping this blog will give me an incentive to actually put my thoughts into words instead of just perseverating on them mentally for several hours a day.