Velotype and Plover

[Gabriel Holmes]

Idle speculation here. I've read a lot about how Velotype is orthographic, while American steno machines is phonetic. Could Plover ultimately blur that distinction? Supposedly, Velotype is "plug and play." I assume this means that as far as the computer is concerned, it's just like any other keyboard. Well, if that's the case, then couldn't Plover work just as well for a Velotype machine as for any other chording keyboard? And if Plover allows the typist to manage his or her own dictionary, couldn't one create phonetic combinations on a Velotype machine which could then be turned into proper English using Plover? Even before I became curious about stenography, I became very skilled at using autocorrect to type faster -- it started by becoming "zen" about typing "teh." For a time, I always felt compelled to go back and correct "teh" until I realized that, if it was changing it to "the" automatically there was no sense in worrying. The next step was getting bolder about deliberately misspelling words: I'd start dropping double consonants (they're expensive!), eliminating spaces (e.g. "ofthe" and letting the computer make the correction for me.) In fact I remember wondering why I wasn't taught to do that earlier. I started pitying all the people who get frustrated by autocorrect, and feel like they've lost control -- when they could take control.

I realize that building a conflict free dictionary -- possibly with multiple levels -- is a lot more than autocorrect. But couldn't the underlying ideas be used for something like Velotype?

Just a thought...

[Gabriel Holmes]

I guess my other line of thinking is: in the end, isn't this all a matter of:

1. Math (number of combinations based on how many options each finger has)
2. Ergonomics (what's possible with our muscles)
3. English phonotactics (what's possible in an English syllable)

Ultimately, all three major options have layouts based on some combination of these.

Is my understanding correct?

It looks like a typical steno machine can produce over 8 million combinations. A machine with "split" sides (e.g. a left and right asterisk key) could very well do better than that. A Velotype machine can do about 5 million (assuming one's fingers are pretty flexible).

[paulo paniago]

Hello Gabriel.

Sorry if I misunderstood your points. I also read about the velotype, and for some time had considered the idea of building my plover dictionary  with a syllabic/orthographic logics.

I was envisioning a very similar approach to that of the velotype. The advantages for me was that it would be easy to learn, to absorb into muscle memory, and to type in different languages (Portuguese/English). Also, I wouldn’t have to go into years of dictionary building.

It would also have a similar fluency to speech as the stenoteories, and not as artificial as the s-p-e-l-l-i-n-g kind of typing of qwerty keyboards.

And again, sorry if I misunderstood your points, maybe its better to wait for the opinion of a programmer like Hesky on this aspect, but, from what it seams to me, the velotype functions in a very mechanical way. Similar to the qwerty keyboard in a sense that it doesn’t manipulate very much the data input you type, except for arranging the letters in a given order, and converting them to say shift and other functions. It even has buttons to make syllables attached or separated by space, where you press it at the same time as typing the syllable.

As it seams to me, if it functions that way, you wouldn’t need plover to make that phonetic dictionary your envisioning. My guess is that a good text expander might do the job.

Also, since the velotype has so many buttons, making it directly translatable by plover, may mean a lot of work to adapt plover for that issue. But its just my guess. 

[Rob B.]

I think this is a good conversation to have. I too have been thinking about this topic (in the general form) since I discovered Plover and have been reading and generally "counting the cost" of steno.

One thing I noticed is that emacs, the text editor I spend a lot of time in, is already a chorded input system due to all the control, shift, and meta keys used. I like that because even for cursor control, I don't need to move my hands all the way down to the cursor keys. I can stay on the main part of the keyboard. Unfortunately other apps do not support the various chords of emacs. One attraction of Plover is that more "shortcuts" would be usable across any application I use.

I think autocorrect and the amazing possibilities for input opened up by having lots of processing power available are worth considering. It seems that steno still holds the speed record, and for speed on plain text it may never be displaced. But steno is optimized for input of properly spelled, full English words spoken in sentences.

For made-up or shortened words that I often encounter in programming, qwerty may have some advantages, since it is more optimized for "fingerspelling".

Both qwerty and steno originated long before computers were even a dream. I think it's helpful to consider how computers might improve these input methods. Also, even something like the Linux command line already has some optimizations that make qwerty less onerous, and neutralize some of the advantage of steno. Commands are short. Common ones are 2 letters long, like ls and cd. The tab key is used to complete longer words; the up arrow is used to access recent commands for editing and reissuing. Most of these operations will be chords in steno. Maybe the chords won't be slower, but they may not be faster either. Some of the chords may end up easier, some more difficult than what is already needed on qwerty.

Qwerty requires the letters to be correctly spelled and correctly ordered in time. But autocorrect is allowing those requirements to be relaxed somewhat. Steno is less dependent on spelling due to phonetics and the fact that multiple steno inputs can translate to the same word (or phrase). Instead of ordering the letters in time, steno (and the veloboard) orders them in space via the rough beginning, middle, and end of each stroke.

If you can spell at a medium level, you can get started with qwerty. You won't be fast, but you can gradually go faster as needed. It's obvious how to write a word: just press each key that you need. The typical steno writer has blank keys. Not all letters are represented, and the words are spelled differently than English according to the theory. Significant learning is needed. The advantage is eventual higher top speed and less finger motion.

Steno requires hardware that allows more simultaneous inputs. An nkro keyboard can accept data faster and has more flexibility for how data is entered than a typical keyboard.

What about a hybrid scheme? Could we blend the qualities of steno and qwerty? We might explore mixtures of chorded and non-chorded input. For example, what if we added chorded "briefs" for the most common words to our qwerty keyboards? Perhaps the "space-t" chord would enter "the ". "space-o-t" might be "of the ". This is only feasible on an nkro-style keyboard. Learning briefs like that for the 200 most common words and phrases in English, along with, say, another 50 personal words we use often may allow a noticeable speed increase without starting over with steno. Each brief you learn gives a tiny boost to your existing qwerty speed and comfort. What if the "s-d-f" chord represented the control key? I could access my fancy emacs control keys faster and without straining my left pinky.

Plover could likely support a hybrid scheme like this on an nkro keyboard with a different dictionary and some code updates to watch more keys than it does now. It might also be helpful to have a change that relaxes the strict "all keys up" rule to allow for fast qwerty-style typing where 2 keys will sometimes be down at once but they should be interpreted as 2 single keys instead of a 2-key chord.

I'm saying qwerty in this email, but the ideas obviously apply to other layouts too.

-Rob

[Zack Brown]

One thing to bear in mind is that the *lack* of chording on qwerty keyboards is actually a strength. If you're typing fast on a qwerty keyboard, you are probably inadvertently chording many letters together. But because you strike each key in order, the overlap doesn't affect the output.

With Plover, or any system that considers chorded strokes as significant, this wouldn't be the case. So in order to blend qwerty and steno systems, you might end up having to type much slower in the general case, just to make sure you never accidentally chorded letters together.

So, your idea of "space-o-t" would probably end up getting "of the" in many cases when someone tried to type "other", "otherwise", "otter", and any other words beginning with "ot".

On the other hand, something like the 'caps lock' key, that would switch from Plover to qwerty and back again, would let you quickly take advantage of both systems. Plover already implements that kind of hot-key switch. Maybe what you really want is that hot-key switch, coupled with a minimalist dictionary file targeted to your particular uses.

Be well,

Zack

--
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/groups/opt_out.

--
Zack Brown

[Drew Neil]

Interesting conversation! Where can I learn more about Velotype? The wikipedia page doesn't tell much: http://en.wikipedia.org/wiki/Velotype

Drew

[Robert Brewer]

Paulo, I can't find what soletration is.  Can you explain?

Yeah, maybe just switching Plover on and off via a fast method is a better way to go.

I'm still wondering if some tweaks to Plover's key up/down logic only for the case of 1 or 2 keys in a chord might allow for modeless operation of both chording and qwerty.  That can be tried without altering which keys Plover is watching.  So perhaps the amount of coding wouldn't be too bad to try some initial experiments.

Something like the ergodox keyboard (when running nkro firmware) seems like it could be very close to the veloboard if there were some sort of modified Plover on the host.

-Rob

On Nov 1, 2013 6:00 AM, "paulo paniago" <ppani...@gmail.com> wrote:

Yes I’m afraid Zack is right, and I can tell you that from personal experience that mixing chording and non-chording typing isn’t gonna make you faster - except if you only chord some specific keys that doesn’t affect the general typing, like shift and control.

I tell you that because, as I was saying I considered making an orthographic/syllabic dictionary, for, as many other reasons, typing in English and Portuguese.

Unfortunately, a hot key like capslock changing chorded to non chorded, would not be a good idea for me, as I was planning on moving completely into a standard stenotype keyboard. And since the idea of creating my own method seemed to complicated, I’ve solved that problem by giving emphasis on soletration.

This way, I would type Portuguese in chorded strokes, and English and other one time only used words in soletration.

As I was already a touch typist of a Brazilian dvorak style layout (called br nativo developed by Brazilian programmer Ari Caldeira) I thought it would be a great idea to map single strokes and very simple chorded strokes (like top and bottom –TS) representing the “one letters” to the closest possible position to the layout I was already good at.

The result was a bit frustrating, since I simply couldn’t type in the way I was used to. When typing fast on qwerty, you basically overlap keys all the time.

I decided to maintain that system of soletration however because, for me, it would be actually better than the one based on the steno alphabet.

I simply accepted the fact that I wouldn’t type as fast for English and other stuffs as before, but, since 90% of my typing is in Portuguese, it wouldn’t be that lost.

Also, it is a slower typing, but I believe it can get to half the typing speed of a qwerty keyboard.

Here is my logics:

Considering that stenotype is generally 2 times faster than qwerty (if your not using a text expander). And that a professional stenotypist can write 200 words/minutes with an average of 3 to 5 strokes a second, depending on the theory (read that somewhere on the net).

An average 4 strokes/second considering a word to be 5 strokes (with space, punctuation…) that would give almost 50 wpm, which is good enough for me.

You may say that attaining that speed would be difficult, as I’m considering the speed of a professional stenographer. But, notice, I’ll be proficient in spelling based on a layout that I′m already proficient.

So:

200 wpm – stenotype

100 wpm - qwerty touch typing

45-50 wpm – my intended soletration.

 

When typing non chorded keys in a chorded keyboard, you simply cannot type in the same manner as in a qwerty keyboard. You got to type with hand motions similar to that of a conventional stenographer, letting go the keys completely before hitting another.

Just my two cents…

--
You received this message because you are subscribed to a topic in the Google Groups "Plover" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/ploversteno/1_aXBbED0a8/unsubscribe.
To unsubscribe from this group and all its topics, send an email to ploversteno...@googlegroups.com.

[paulo paniago]

Oh, I′m sorry Rob. 

Soletration is something I just translated wrong. I meant spelling. (in Portuguese spelling is soletração)

[paulo paniago]

 Hello Drew, I did some searching on the velotype but couldn’t find anything except pictures. I read about it a very long time ago, If someone find anything, i′m also curious.

 

Hello Rob, I realized that my explanations was really unclear, so I decided to change it ounce again:

 

“Yes I’m afraid Zack is right, and I can tell you that from personal experience that mixing chording and non-chording typing isn’t gonna make you faster - except if you only chord some specific keys that doesn’t affect the general typing, like shift and control.

I tell you that because, as I was saying I considered making an orthographic/syllabic dictionary, for, as many other reasons, typing in English and Portuguese.

Unfortunately, a hot key like capslock changing chorded to non chorded, would not be a good idea for me, as I was planning on moving completely into a standard stenotype keyboard. And since the idea of creating my own method seemed to complicated, I’ve solved that problem by giving emphasis on spelling.

This way, I would type Portuguese in chorded strokes, and English and other “one time only” used words in spelling.

 

So, I wanted to make my spelling the best and fastest possible, even sacrificing some commonly used briefs if necessary. And here is what I did:

 

i was already a touch typist on a qwerty keyboard (actually mine is called br nativo, but you get the point).

So, I map the spelling in plover dictionary to be the as similar as possible to the keyboard I was already using.

 

I thought making spelling that way on plover would be a great idea because I would readily be good in spelling at stenotype, and also wouldn’t throw away my years of touch typing training.  But the result was frustrating since I simply couldn’t type in the way I was used to.

When typing fast on qwerty, you basically overlap keys all the time. And that doesn’t work on a chorded keyboard. I discovered that when typing non chorded keys in a chorded keyboard, you simply cannot type in the same manner as in a qwerty keyboard. You got to type with hand motions similar to that of a conventional stenographer, letting go the keys completely before hitting another.

So, if I had to type one key, and than only after it had raised completely, I could type the other, that would make my typing really slow.

 

However, how slower would my spelling with plover be, when say, compared to qwerty touch typing?

My guess, from some informations I found on the net, was that I could expect to have about half the speed of a good qwerty touch typist. This would be, perhaps nearly 50 words/minutes - which doesn’t seams bad to me.  

Using plover to type fast in Portuguese and to spell at 50 wpm in English was actually motivating.

 

Here is the logics I use to get to my expected 50 wpm spelling with plover (from information I found on the net):

. Stenotype is about 2 times faster than qwerty touch typing.

. A professional stenographer writes about 200 wpm. - This means a very good qwerty typist with correspondent training would have 100 wpm.

. A stenographer typing at 200 words minutes would be giving 3 to 5 strokes per second, depending on the steno theory.

 

So:

 as 5 strokes on a qwerty is generally considered to be counted as a word.

If I type 3 to 5 strokes a second when spelling, that means that I would be writing 3 to 5 letters a second with plover (already counting spaces, points…)

 

This brings to the conclusion that:

Spelling an average of 4 letters a second would give me almost 50wpm.

 

I know it is difficult to type the strokes with the speed of a professional stenographer. But if I set the spelling to be really easy and in a way I am already familiar, that wouldn’t be so hard.

So:

200 wpm – stenotype

100 wpm - qwerty touch typing

45-50 wpm – my intended spelling.”

 

Hope its clearer now.

[Shaan Iqbal]

Interesting thread. At the moment I'm inventing a lot of abbreviations for the most common words, e.g. t->the, y->why, etc. In this way you can reduce keystrokes by over 50%. The fact that the abbreviations are my own, instinctive ones makes them easy to remember. I understand that there's a program called Typewell has its own abbreviation system where you write the skeleton outlines of words, allowing you to type at around 180wpm. I haven't tried Typewell yet. At the moment I'm using the program Asutype. I add abbreviations to its autocorrection list. I plan to learn abbreviations for, say, the 300 most common English words, as my minimum target. Like Rob said, just learning the common words alone should give you quite a boost in Qwerty. And then any other abbreviations on top of that are a bonus. This is a manageable target, and doesn't require you to learn an entirely new system. You just type as normal except for the abbreviations words you've learned. 

On Friday, 1 November 2013 01:57:50 UTC, Gabriel Holmes wrote:

The next step was getting bolder about deliberately misspelling words: I'd start dropping double consonants (they're expensive!), eliminating spaces (e.g. "ofthe" and letting the computer make the correction for me.) 

Gabriel, I also thought about eliminating spaces entirely from typing as a way to shave off keystrokes. I know that Swiftkey on my android phone is able to autocorrect unspaced wording up to a certain number of words, so you can type hellohowareyoutoday and it'll autoinsert the spaces.  I've always wondered why a similar program isn't available for PCs. It would be great if someone could program a system that meant you NEVER had to press the spacebar at all, adding spaces automatically, EXCEPT for words that combine to make other words, where it could ask you to add a space manually. Does anyone know of such a program? What autocorrection program are you using by the way? 

On Friday, 1 November 2013 06:46:03 UTC, Rob B. wrote:

 

What about a hybrid scheme?  Could we blend the qualities of steno and qwerty?  We might explore mixtures of chorded and non-chorded input.  For example, what if we added chorded "briefs" for the most common words to our qwerty keyboards?  Perhaps the "space-t" chord would enter "the ".  "space-o-t" might be "of the ".  This is only feasible on an nkro-style keyboard.  Learning briefs like that for the 200 most common words and phrases in English, along with, say, another 50 personal words we use often may allow a noticeable speed increase without starting over with steno.  Each brief you learn gives a tiny boost to your existing qwerty speed and comfort.  What if the "s-d-f" chord represented the control key?  I could access my fancy emacs control keys faster and without straining my left pinky.  

I too thought about the combination of Qwerty by itself and chorded input. I think if we were to have a system like Plover that ONLY affected 3+ letters pressed at the same time, where they all HAD to be pressed together (you couldn't "roll" the chord) then you wouldn't run the risk of typing really fast and having a chord be outputted by mistake. I almost never hit three keys at the exact same time even typing very quickly, ~140wpm. It would be amazing if Hesky or someone could program this.  I tried the autohotkey script here: http://www.autohotkey.com/board/topic/40874-chording-script/ . Unfortunately it only allows you to chord two keys at a time, and it caused problems with Asutype. I found that setting delay to 40 milliseconds was good. And you can set chords to letter combinations that would be unlikely to occur in regular typing, eg. "ws" "df". Actually, even setting combinations that did occur together like "ps", with the 40millisecond delay, didn't seem to cause me problems typing, say, "psychology", at my normal rate. 

On Friday, 1 November 2013 10:10:25 UTC, Zachary Brown wrote:

On the other hand, something like the 'caps lock' key, that would switch from Plover to qwerty and back again, would let you quickly take advantage of both systems. Plover already implements that kind of hot-key switch. 

Zach, I would LOVE it if I could just press my caps lock key to toggle Plover on and off. I currently have toggle assigned to PHROLG, but caps lock would be way better. Could you tell me how to do it? 

 On Fri, Nov 1, 2013 at 2:46 AM, Rob B. <rwb...@gmail.com> wrote:

I think autocorrect and the amazing possibilities for input opened up by having lots of processing power available are worth considering.  It seems that steno still holds the speed record, and for speed on plain text it may never be displaced.  But steno is optimized for input of properly spelled, full English words spoken in sentences.

On the subject of autocorrect, I'd really like to know which programs you (Rob), and Gabriel are using? Autocorrect is something that I've been very interested in as well. While smartphones' autocorrection systems seem to be getting smarter and smarter, PCs are severely lacking in this area.

I've tried out all sorts of autocorrect programs that would work globally, ie. not just on Microsoft Word but on any Windows program. First I tried Global Autocorrect but that was slow and cumbersome, and didn't have a lot of the features I wanted. It couldn't even autocorrect "i" to "I". Then I tried Zero Click Spellchecker, which was better, and then finally, the one I'm using now which is very good, but still not perfect, is Asutype. It has most of the functionality I want, allowing me to, for instance, set it to replace accidental double spaces with single space, which is something I do a lot when typing fast, and automatically writing out words like 1, 2, 3 up to 21 in word form. It also autocorrects globally, although this still doesn't seem quite as smart as Microsoft Word, Swiftkey on my Android, or my iPod touch. I definitely would like more and better auto correction programs for PC.

[Robert Brewer]

My mention of the power of autocorrect is more about what I've seen on my Android phone than anything I have on my PC.  I do notice it helping me in Outlook, but I really don't have it elsewhere.  On my phone I'm learning the shortcuts I can "get away with" and have them autocorrected away.  It's unfortunate that these input advances haven't been applied much on the PC.  I think people are focused on getting their phone speed closer to the PC, and haven't fully realized that the same techniques can make the PC even faster. 

I find it difficult to go "back and forth" interacting with an input system.  For example, in swiftkey I can only really use the predictions if it's the one that will be chosen when I press the space key.  Perhaps with more practice I could develop a better flow with it.  It's another reason that I think deterministic briefs are easier than predictions, where I need to focus on what it's trying to tell me instead of what I'm trying to tell it.

I'm working on a separate message on the hybrid qwerty and chorded ideas.  Shaan's experience is helpful for that, especially since you can type much faster than me.

I use Linux a lot, so cross-platform solutions like Plover are most useful for me. 

-Rob

[Robert Brewer]

Thanks for the explanation, Paulo.

Here's a possible algorithm to differentiate qwerty and steno typing on the fly.  I don't have time to code and test it yet but thought I'd write it down and get feedback.

I am considering key down and up events and ignoring modifier keys, since they aren't part of what Plover watches anyway.  For now I assume a fast qwerty typist will have at most two keys down at a time, so the goal is to decide whether the typist intended 2 separate qwerty keys or a single 2-key chord.  My notation is Ad Au for a key A down event followed by a key A up event, and Bd Bu for B key events. 

Case 1:  Ad Au    Bd Bu - this is slow qwerty typing with key A, some time, then key B

Case 2:  Ad Bd      Au Bu - this has a lot of time between down and up of both keys, so the typist intended an AB chord

Case 3:  Ad    Bd Au     Bu - this is fast qwerty typing.  There is a small time window when both keys are down.

Case 4:  Ad Bd Bu Au - I contend that although this is fast, the fact that B goes down and up while A is still down means this is an AB chord and not fast qwerty typing.

Case 5: three or more keys down at the same time is assumed to be a chord.

Case 1 is easy to distinguish in code because only 1 key is down at a time.  Case 4 is also easy because it is ABBA.  Case 5 is easy too. So the hard part is to distinguish between cases 2 and 3.  There are three time intervals in those cases: AdBd, BdAu, and AuBu.  There is also the total time, which is their sum.  I think that if BdAu is greater or equal to one-third the total time, we choose case 2 (a chord).  If BdAu is less than one-third the total time, we choose case 3.  The nice thing about making it proportional is that the algorithm can provide good recognition across varying typing speeds even for the same user.  At least that's my hope; it would need to be tested. 

In all these cases, we could send the key to the application immediately on the down events.  This way the qwerty typists see their keystrokes immediately like they are used to.  For case 4, we notice a chord is being entered at Bu, so we backspace the A and B keys already issued and wait to generate the translated chord once all keys are up.  Case 2 is similar, but we don't realize it was a chord until the very end at Bu.

As Shaan mentioned, we could also solve this problem with some combination of disallowing 2-key chords; requiring that 2-key chords are never "rolled" (so they are always case 4); or by the user managing the dictionary to not use 2-key chords that are easily confused with common qwerty letter pairs.

-Rob

[paulo paniago]

Hello Rob, that’s very interesting.

I think that to eliminate the conflict between chording and non chording it would be much more difficult than with the system you proposed, because seams to me, chording is much much easier than what we would normally imagine.

 But even than, that might be a very good beginning, and I would like to ask that you don’t give up on the first results. You might be giving birth to a whole new theory.

 If your project is viable, and I know it is early to be asking for features, but I would like to ask for a system of preferences. A mechanism that would allow the user to choose which combination of keys he would like the program to preferably recognize as chording, and which as non chording. However, I’m going to wait to see what others more experienced have to say on the subject to better decide on my expectations.

 Wish you success on that attractive hybrid system.

[Fred James]

My spouse is currently studying CRAH which is supposed to eventually lead to using a windows machine with "case catalyst" software.� Our machines are all Linux, and have been for years.

I haven't gotten any knowledgeable answers so far, but what I am guessing is that we should be able to put together a working setup with
��� Plover
��� Linux
��� case catalyst
does that sound doable at all?

I am further guessing that what I will need from case catalyst for this setup, is the dictionary ... does that sound right?

I would greatly appreciate any input/suggestions ... I am trying to get a little jump on this to be prepared, eh?

Thank you
Regards
Fred James

PS:� so far all the steno has been done on paper only ... we don't have the case catalyst as yet ... although I did have Plover installed and working on my Linux box before I upgraded.� I don't know steno myself, but I was able to get predictable output on my screen using a qwerty keyboard in steno mode.

[d32210]

CaseCat is not useable with Linux. If you don't want to go with Windows, the Plover is your only option. That is certainly not a bad thing, but you will eventually need to go the windows route when it comes time to work in the field.

Plover will load any dictionary, and is perfectly fine while a student. 

If you can find a cheap laptop online, I would go with windows and CaseCat. Just better to learn it from the start. 

Sent from my Samsung Galaxy™ S II 4G

Fred James <fred...@fredjame.cnc.net> wrote:
My spouse is currently studying CRAH which is supposed to eventually lead to using a windows machine with "case catalyst" software.  Our machines are all Linux, and have been for years.

I haven't gotten any knowledgeable answers so far, but what I am guessing is that we should be able to put together a working setup with

    Plover
    Linux

    case catalyst
does that sound doable at all?

I am further guessing that what I will need from case catalyst for this setup, is the dictionary ... does that sound right?

I would greatly appreciate any input/suggestions ... I am trying to get a little jump on this to be prepared, eh?

Thank you
Regards
Fred James

PS:  so far all the steno has been done on paper only ... we don't have the case catalyst as yet ... although I did have Plover installed and working on my Linux box before I upgraded.  I don't know steno myself, but I was able to get predictable output on my screen using a qwerty keyboard in steno mode.

--

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.

[Robert Brewer]

I'm trying not to count the chickens before this idea is tested.  But if the error rate is low enough, another way to view it is a way of inputting single-key chords faster than what plover currently allows.  The single-key chords could translate as steno, qwerty, or whatever; that choice could be controlled by the dictionary you load.  Since there are only 23 or so single-key steno chords, it wouldn't be a large change in terms of steno theory to replace those 23 steno entries with qwerty entries when running on a sidewinder.  Or just make up your own chorded abbreviations, or whatever mixture you like. 

-Rob

[paulo paniago]

Hello Rob,

I think that eliminating conflict is very difficult because, as I read about rsi, when you press a key on a qwerty keyboard, the hardware doesn’t wait for the key to be completely depressed for giving the signal. Most keyboards send the signal  ¼ or sometimes at 1/3 before the keys go all the way down. That means that everything going on simultaneously at that last interval of 1/3 or ¼ would be already chording.

 The system you propose would be effective for me, I think, as I intend to use a standard steno keyboard like the stenosaurus, and so, my movements would be more like that of a stenotypist. So this mechanism of key up – key down in sequence would diminish the error rate.

But I imagine a fast qwerty typist, at 140 wpm like Shaan would be chording much more than what  would be corrected with a one on one key system. Actually a typist that fast, unless pressing very superficially on the keys, would be chording much more than 2 keys at a time.

 About the system of preferences I proposed, I guess your right, that could be simply set in the dictionary. So I thought of a different way of still implementing that idea.

 See, I realize that when I spell, using the stroke {&x}, the next stroke would much  likely be another spelling. So I would like to suggest that, you could make a system that was activated by {&x}  and/or other symbol associated with spelling, and that it would be deactivated only when it saw a clear enough chorded stroke. As I see, that might actually make things easier as you could make a much less tolerant system that wouldn’t interfere with general chorded typing on plover.

Just my thoughts…

[Fred James]

My apologies ... either I didn't state my question carefully enough, or
I didn't understand the answer (as in I don't have a complete enough
understanding of the situation, perhaps?). So I beg your tolerance,
please, while I try again.

I agree that the CaseCat (case catalyst) software will not work on
Linux, it having been written/compiled for Windows (only, I believe).

However ...

Steno theory is (correct me if I am wrong, please) the keystroke
combinations (cords, if you will) that equal the output (words, phrases,
punctuations, spacing/formatting, and briefs). If that is true, then
the "theory" is embedded in the look-up (table/file), or dictionary?
Such that, given a proper dictionary, software like Plover should be
able to support any theory. Or, if your prefer, the part of Plover that
supports the connection between a keyboard and a computer, should be
able to support any theory, again, given a proper dictionary.

Is all of that correct so far? Please supply any missing pieces, and/or
clarify any stuff I may be/seem confused about. Thank you
Regards
Fred James

(omissions for brevity)

[Zack Brown]

I believe that's correct. The dictionary file represents the full steno theory. If you use a different dictionary file, you're using a different steno theory.

And I believe it's also true that Plover can support any steno theory, just by changing the dictionary file. But it's possible that the Plover software may be slightly hard-coded to work with Plover theory, because of supporting suffix chords outside of the dictionary file.

--
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+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/groups/opt_out.

--
Zack Brown

[Fred James]

Zack Brown
Thank you for your reply.  Could you clarify "supporting suffix chords outside the dictionary file", please?

Thank you
Regards
Fred James

Zack Brown wrote:

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/groups/opt_out.

--
Zack Brown

--
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.

[Mike Neale]

http://plover.stenoknight.com/2013/07/plover-251-released.html

Suffix folding: when a suffix stroke (-G, -D, -S, -Z) is used and the outline is not in the dictionary then the outline is looked up without the suffix and then the suffix is added. For example, if TURPB was turn and -G is {^ing} and TURPBG is not in the dictionary then if you stroke TURPBG Plover will output turning

[Mirabai Knight]

On Mon, Nov 4, 2013 at 3:47 PM, Mike Neale <mig...@gmail.com> wrote:
> http://plover.stenoknight.com/2013/07/plover-251-released.html
>
> Suffix folding: when a suffix stroke (-G, -D, -S, -Z) is used and the
> outline is not in the dictionary then the outline is looked up without the
> suffix and then the suffix is added. For example, if TURPB was turn and -G
> is {^ing} and TURPBG is not in the dictionary then if you stroke TURPBG
> Plover will output turning
>

This is definitely not specific to Plover theory; most if not all
English theories use -G for ing, -D for ed, etc. But, of course, this
wouldn't map as easily to steno theories in other languages.

[paulo paniago]

Oh I’m sorry Rob, I gave you some wrong numbers  - the sensor on qwerty keyboards detect the key pressed at ¾ or sometimes at 2/3 of the way, before the key get to the bottom. So anything in that last  25% range, moving simultaneously with other key, would be chording.

[Fred James]

If "TURPB" is in the dictionary as "turn" but "TURPBG" is not defined in
the dictionary, then Plover (and other steno software) would add "ing"
and output "turning"

But if "TURPBG" was defined in the dictionary, Plover (and other steno
software) would just output what was defined
Is that right?

In short, if one didn't want "TURPBG" to produce "turning", one would
have to define "TURPBG" in the dictionary?
Is that right?

[Robert Brewer]

​Paulo, I did some quick experiments with my new keyboard and found that for words I can type very fast the OS does see 3 keys down at once.  I'm hopeful that the character of fast typing is still different enough in that situation to be distinguished from chording, but I think I'll have to get a prototype going and experiment on myself and some faster typists to get a better idea.

​What you're suggesting about biasing the current recognition of individual keys versus a chord based on the recent recognitions is a good idea and may not be as difficult as I was originally thinking.  I imagine it would help to improve the accuracy overall.  I find that my own typing varies a lot: for words that I'm very good at typing I can pump them out quickly, but ones I use less often or involve more reaching, I'm much slower at and often have some hesitation.  So my typing tends to be sort of "choppy".  ​

​

​I'm thinking that's the sort of case that is difficult to handle in distinguishing typing from chording.  

-Rob

--
You received this message because you are subscribed to a topic in the Google Groups "Plover" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/ploversteno/1_aXBbED0a8/unsubscribe.
To unsubscribe from this group and all its topics, send an email to ploversteno...@googlegroups.com.

[paulo paniago]

Hello Rob, I was hopping to have a better moment to answer you, but I′ll post a better message latter.

But basically, what I wanted to suggest you is that you don’t get to focused on such a precise, timing dependent system. That might be very difficult to handle.

Instead, maybe you could focus on a system that works really well when it is activated to turn off chording.

I think that there is no problem in letting the USER gain the necessary ability, with time, to change the chording /non chording hybrid system. All the user got to do, as I’m imagining, would be typing the first spelling really clear, and than, as the system would be activated, he could then relax the fingers. The non chording would again be deactivated when it saw a chord really, really clear.

Also, I would like to suggest that other spellings with {&x} would be seen as non chording, even if it was chorded on typing. But I will explain it latter. 

[paulo paniago]

 Hello Rob, I believe you got the point. That “choppy” typing, the most common (which also includes mine) can mess with the whole thing.

Also, there are times when we like to type slowly, thoughtfully. It would be inconvenient to have an application “changing rules” in the middle of the game, just because you changed your typing speed. That also may take you out of that absorptive, precious moment.

And I think, a sophisticated enough typist to actually try steno and to be interested in a hybrid non chorded / chorded version, would also like to have control of these changes. Especially when they are not inconvenient, like pressing extra keys, forgetting to press again the extra key to return to the state before, changing keyboards...

 Let me show you how I’ve set my spelling (I was going to use the qwerty and us steno keyboard just to illustrate, but got all confused, sorry for that. Anyway you don’t need to look at the specific keys to letters – I just want to show how I map the rows on each other):

 

 In “qwerty” keyboard, I use a Brazilian stile dvorak called br nativo, developed by Ari Caldeira in 2006:

/,.hx wltcp    1 first row

ieaou mdsrn  2 home row (the one with the vowels)

yçjbk qvgfz    3 third row

 

and I′m learning steno with the Brazilian Portuguese layout:

 

SKFL**RBGTD     1first row

STPR**WPHSZ      2 second row

     AO    EU             3 third row

 

So I map my 1 first steno row to be similar my 1 qwerty:

 

 

 

 

1 steno row

K

F

L

L*

*R

R

B

G

T

D

1 qwerty row

/

,

.

h

x

w

l

t

c

p

 

where R types l, B types t, G types c and so on.

 

Now, the   2 second steno row, in my mapping goes with the 3 third row on my qwerty (and not the middle row):

 

2 steno row

T

P

R

R*

*W

W

P

H

S

Z

3 qwerty row

y

ç

j

b

k

q

v

g

f

z

 

 

The only exception to this was steno S that doesn’t have “up and lower” values

 

Now, and that’s what I wanted to show you – my   2 middle row in qwerty is all chorded from very simple, generally 2 keys strokes (sometimes 3 keys):

 

2 and 3 steno rows

S

KT

FP

LR

LR*

*RW

RW

BP

GH

TS

DZ

2 or home qwerty

i

e

a

o

u

m

d

s

r

n

 

(if anyone is wondering: A-U together goes for my SPACE BAR)

 

So, as you see, the middle row on my qwerty, which is the most important row on a dvorak keyboard (on br nativo, the one I use, the middle row makes 78% of all typing in Portuguese) is all chorded and goes for the “middle” row on my steno, being a combination of the   1 first and 2 second steno rows.

The reason I wanted to show you this, is that a hybrid chorded / non chorded user, unless he intend to stay the rest of his life on qwerty based keyboards such as the sidewinder, he will want to chord many of his spellings simply because the number of keys differ in each device.

 So for it to be effective on a standard steno keyboard, it would have to recognize chords, but in a different manner than when doing the other strokes.

What I would like to suggest is something like different  rules for spelling. When spelling, it would generally select the {&x} over other keystrokes that came overlapping. I don’t know if it is possible, since I don’t understand of programming, but I believe it would be an awesome system.

In this system, as I said before, the user would develop the ability to change from chord/non chord by making very neat movements.

 Hope that helps!!!

 

[paulo paniago]

(I just erased a question that sounded like criticism, sorry for that)

Hello Rob, part of our discussion was already going on in this group.

 Take a look; there are some valuable information:

Plover Proposal: Option to return Qwerty values for all non-chorded keystrokes in keyboard mode.

https://groups.google.com/forum/#!topic/ploversteno/rJmEDnXU_fY

 

[Robert Brewer]

Paulo, neat, I've been wondering if a middle steno row like you are using is feasible.  Thanks for taking the time to explain it.  I'd like to understand your setup a little better: where are your steno vowel keys?  Does your keyboard have additional keys near the thumbs like the Kinesis or ergodox?

When you describe the {&x}, are you wanting the software to check the dictionary and if the resulting translation would be a single letter, to prefer that over an entry that translates to a full word?  I hadn't thought of that and it seems reasonable to try. 

I have a feeling there will be a few situations that require different rules to get good accuracy.  We'll probably need to experiment and there may not be a one-size-fits-all way of doing it.  I can imagine if I'm starting off learning in a mostly qwerty mode, I may want it to prefer qwerty unless it's very clearly a chord.  But as I learn chords and type them faster, I may want it to be neutral about qwerty/chord.  Finally, if I'm very fast and mostly chording, I may want it to prefer chording unless it's clear I'm using qwerty. 

I'll probably try for something with adjustable parameters so we can experiment with different settings to get a feel for how it works.  What OS are you using?

I did see the other thread you posted at one point and I think that shift key toggle tip may be an 80% solution for what you are doing.  I'm not sure if I'll do full steno for myself or not yet, so I'll probably continue this investigation for a bit.

-Rob

[paulo paniago]

 

 

Hello Rob, let me answer your questions, one by one:

I'd like to understand your setup a little better: where are your steno vowel keys?

 

If you look at the Brazilian steno layout:

http://www.stenograph.com/pages.aspx?docid=248&id=

You will see that the vowels are in the same position as yours. I use them just as my theory require, except only in two cases, both related to spelling:

 - As I told you, I made considerable changes in my method to emphasize spelling, even if it meant to sacrifice common briefs. So, to make spelling the easiest possible way, when I set it to resemble my “qwerty” keyboard (br nativo) I’ve mapped A-U (chorded) to be my “spacebar”.

- The other change was that I didn’t use them anymore in spelling. So FP will   be {&a}, LR will be {&o} and so on.

 

Does your keyboard have additional keys near the thumbs like the Kinesis or ergodox?

I use the sidewinder, and I’m actually avoiding any extra keys that are not in the standard steno machine, as I intend to migrate completely into one of those. Specifically I’m dreaming with the stenosaurus connected to a tablet pc by a case or a joint, turning it into a “steno capable laptop”. With that said, I confess that I’m using hotkeys as capslock and shift more often than I hoped to, even when spelling.

 

When you describe the {&x}, are you wanting the software to check the dictionary and if the resulting translation would be a single letter, to prefer that over an entry that translates to a full word?  I hadn't thought of that and it seems reasonable to try. 

That’s exactly the point, do you think it is viable?

 

We'll probably need to experiment and there may not be a one-size-fits-all way of doing it. 

Well, I strongly recommend a one size fits all project. Different versions of plover will be interesting for tests, to evaluate advantages and disadvantages between different users, but the final product is primarily, in my opinion, to be a single program goal. Take a look at Hesky′s quote in the other post:

 

I prefer this proposal because the required steps are generally useful for steno, which is the Plover's purpose without creating more special cases that will only serve a small set of users.

He said that about a 4 steps alternative he conceived for the qwerty/steno proposal.

If you permit me to say, I think that could be a main priority of your system. Make something that will generally be used in steno. Based on that quotation, I see advantages and disadvantages related to a hybrid system:

Disadvantage is that, it is likely that the folks at plover wont be interested in small variations of the plover program, fragmenting its users in different niches and perhaps even confusing new comers. Also - having to deal with bugs in different versions wouldn’t be very attractive for them.

 The advantage I see in focusing your efforts to make a mechanism that would be adopted in plovers mainstream, is that it might actually relax parameters a bit. See, you won’t have to make a completely reliable, precise, hybrid system, changing chorded to non chorded on the fly. If you only manage to make it increase, as you said, “the overall accuracy”, it would be more than enough reason for it to be adopted by the plover project - It would be great achievement by itself, and I would be more than be grateful  : ) 

 … because, as Mike Neale expressed much better than myself in the other post, about accidental chords with fast typing (he made the experiment of mapping the steno dictionary in a qwerty arrangement, I think):

I have to say this downside is huge. I tried something similar to this recently and I found that when typing at anything above 20wpm in a natural way, EVERY key overlaps with the next. Although it may seem that we press each key sequentially, we really don't. We flow from one key into the next.

So, again, the problem of avoiding chords “on the fly”, may be much more difficult than it seams.

But you made a  point here:

I'll probably try for something with adjustable parameters so we can experiment with different settings to get a feel for how it works.

That is a very wise decision, and even if it doesn’t work, it may show us an unexpected benefit in other areas and subtle options or possibilities of improvement that was not clearly visible at first.

 

 And by the way, I’m using the last mac os x 10.9 - the mavericks ; )

 

 

 

 

[Hesky Fisher]

That's correct.

--
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+unsubscribe@googlegroups.com.

[Fred James]

Hesky Fisher wrote:
> That's correct.
>
(omissions for brevity)
Thank you ... two more questions, if I may please?
(1) I want to connect a Stentura 400 SRT to my computer. The 400 SRT
has a DB9 female port and the computer doesn't. All I have is USB (2.0
and 3.0). Do you know if any cable will work, or do I need a special
one? The cable that came with it seems to be proprietary Stenograph
stuff (a length of RJ45, straight flopped cable, and two Stenograph
RJ45/DB9 connectors ... one marked writer and the other marked cpu).
(2) I want to create a dictionary from scratch ... can you point me
toward how to do that, please?

[Hesky Fisher]

Hi Fred,

I'm not sure if the cable you have for the 400 SRT is a normal serial cable or if it has some custom wiring (I suspect it's custom) but you should be able to use any USB-Serial adapter to connect it to your computer.

Regarding creating a dictionary, it depends on what you want help with. Plover doesn't yet have an integrating UI for modifying dictionaries. But that would only be part of the problem. The other part would be whether you need anything other than tools for manual dictionary editing.

Hesky

Fred James

[Fred James]

Hesky
Thank you for your reply, and the cable information.

Dictionary:  I am OK with manual editing, and I have the tools for that.
Regards
Fred James

Hesky Fisher wrote:

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/groups/opt_out.

--
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.

[Robert Brewer]

Paulo,

Thanks for describing your setup some more for me. 

I should probably reread that other thread  since it seems I missed some of the details you mentioned about Mike's experiments.

Seeing your last message, I think we are pretty close in our ideas.  I'd rather not have small splinter projects either, and I think faster single-key chords may help Plover too. 

The difficulty for doing these experiments is that Plover makes the (quite reasonable) decision to only worry about steno input in various places in the code.  I haven't looked deeply enough to see how difficult that is to generalize.  As we're seeing by other messages on this group, it may be that Plover needs to generalize some of that anyway to support other languages besides English. 

My current thinking about the experiments is to have a few different "factors" that are in the code to help distinguish single key from chorded input and have some configuration parameters to tune them.  Then we can play around with different settings to see how it works. 

Unfortunately MacOS is the OS I don't have available for testing.  So once I have something starting to work with Linux or Windows it may take some fiddling to make it work on Mac.  It shouldn't be too bad since Plover already does it, but often there are details that need to be fixed.

-Rob

--

[paulo paniago]

Hello Rob, I m traveling - in a city called Goiânia.

I’m trying to buy a second hand, but new, noppoo choc mini (a small usb keyboard that works with plover) veeeeeeeeery exciting!!! I’ll tell about it later.

I think you are in the right way, but will answer you next week!!!

[Brent Nesbitt]

I'd like to hear your impressions of that keyboard.

--

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.

[paulo paniago]

 

 

Hello Brent,

Maybe the Noppoo Choc will be here at Friday (I hope).

I use a macbook, and this keyboard is known to have “issues”, using with it. So i′m with a little “freeze” (cold – frio) in the stomach. But, once it arrives, I’ll post in here my impressions. 

 

Hello Rob,

As we're seeing by other messages on this group, it may be that Plover needs to generalize some of that anyway to support other languages besides English. 

I don’t understand of programming to properly argue with that, but, as it seams to me, all generalization, in plover, was made by the urgent necessity of actually turning it into reality. From what I could understand, it seams to me that, when Josh created plover, the main worry was to make it work in a viable way.

Those generalizations, (sorry, I don’t know precisely what we are talking about here), I think would be, probably, to make plover flexible, and so, adaptable to many different machines and protocols, from professional stenturas to inexpensive n-key rollover keyboards. Also for it to be used as a “base element” to be increased by contributions, like yours - making the program in a simple, more readable language, and flexible to allow modifications, would be, as I believe, more attractive to volunteers. In this way, the configuration style of plover would contribute to its development in the kind of dynamics proportioned by an open source system. So, in other words, I believe he made it that way, so it could naturally evolve. 

 

Unfortunately for me, as I believe, making it adaptable for other languages is only a bi-product in with Josh probably couldn’t have the “luxury” to worry about. Plover, although wonderfully adaptable, has it′s functioning intrinsically associated with the English language.  

For instance, other languages have different letters than used in English, and those were not supported, and not easily added, until recently, when Hesky made the last upgrading. Also, many inflexions of suffixes and other orthographic rules are native in plover, and sometimes, require quite expertise knowledge to change them. Another thing - some languages have layouts with more keys than the standard English one, and so, to increase the number of keys used by plover, in Hesky′s words “is not trivial”.

So, I think that, when you try to understand plover′s functioning, you only need to concentrate on its work throw the English language. Don′t worry about how it could be used differently, just look at how it converts the many forms of input signals, and how it handles them in different environments. Even though I don’t understand of that, I can imagine, it is already a lot to think about. 

 

 

Also, I don’t know if it would be relevant to this proposed system of spelling, but I would like to give you more details of how I’m doing my plover to work in English and Portuguese. 

As I told  you before, I’ve emphasized spelling, making it very similar to my “qwerty” keyboard (br nativo) so I could expect to have up to 50 wpm when only spelling in English. This way, I would use plover to write fast in Portuguese, and at 50wpm in English.

Well, since than, I began making two separate dictionaries. One large for Portuguese, and another - much smaller, for English.

In the English one, I’ve put all the spelling, punctuation and commands that would be common to both.

Now, with that said, in the English dictionary, I’m also writing chorded strokes for the 1000 most common words of English.

- From this site:

http://www.inglessozinho.com.br/1000-palavras-mais-usadas-em-ingles-para-aprender-sozinho/

 

This way, I believe, those common words will probably make more than 50% of my typing. So I can expect much more than those 50wpm when I properly train it. I decided to make this in separate dictionaries, because, this way, I could use the same strokes with different meanings, when changing languages. Also, if I ever intend to increase the vocabulary of my English chording, I wont have to figure out complex rules to avoid conflict between the two languages - since they will be separated.

Actually, what I wanted to say is that, even when giving emphasis on spelling, I would probably be migrating, little by little, into chorded movements. So, I would like to add that, if I’m gonna do it this way, other “base spellers” might probably follow the same way.

When I said in the last post, that I think you are in the right way, I was referring to this:

“My current thinking about the experiments is to have a few different "factors" that are in the code to help distinguish single key from chorded input and have some configuration parameters to tune them.  Then we can play around with different settings to see how it works.” 

Hope it works!!!