Hospitals no fun, not talking worse.

[DavidS]

If only one day we could develop a language for communicating among each other that mirrors the simplicity, structure, and eloquence of the likes of MIPS assembly language, or C, or even BCPL. If this task were to be accomplished, without loss of ability to achieve complete transmission of concept, then we would have a truly usable human language.

Until then we must work with the extreme imperfection of the spoken languages and signed languages we use to communicate. Even when communicating through text means we are using a mirror of our spoken language.

It does make me wonder, the language processing in my brain is so messed up that I can not form spoken language, and can not correctly form signed language, though yet I have very little trouble forming written language, and I still understand all three forms without issue.

Make that typed, not written, I also am no longer able to write, as in with a pen on paper kind of write.

[DavidS]

Actually I must amend my previous statement, as it is dificult for me to correctly comprehend written language now, I really have to work at it. That is unless it is something I typed, in which case I do not have any trouble in understanding it.

Though I have been told that I am making omissions in my typed language that I did not make before, I am unable to perceive this, so I can not comment.

[DavidS]

Still moving slowly. One step forward per day may end up being the reasonable expectation with this project.

Though today I am not likely to make any real progress, it is a doctors visit day.

[mikerr]

If only one day we could develop a language for communicating among each other that mirrors the simplicity, structure, and eloquence of the likes of MIPS assembly language, or C, or even BCPL. If this task were to be accomplished, without loss of ability to achieve complete transmission of concept, then we would have a truly usable human language.

That is/was the idea of Esperanto. An artificially constructed language with proper rules consistently applied and all the silly exceptions and irregular verbs stripped out.
Not used as much as it might have been - I think china uses it most.

Until then we must work with the extreme imperfection of the spoken languages and signed languages we use to communicate.

Even when communicating through text means we are using a mirror of our spoken language.

That's true of most languages, but not of chinese / mandarin for example.

[DavidS]

If only one day we could develop a language for communicating among each other that mirrors the simplicity, structure, and eloquence of the likes of MIPS assembly language, or C, or even BCPL. If this task were to be accomplished, without loss of ability to achieve complete transmission of concept, then we would have a truly usable human language.

That is/was the idea of Esperanto. An artificially constructed language with proper rules consistently applied and all the silly exceptions and irregular verbs stripped out.
Not used as much as it might have been - I think china uses it most.

Unfortunately a language that has not caught on, and is unlikely to. The correct people are not pushing for such a language, even though it would make a great trade a language. It would be a great trade language for the modern world in the same way that the "Common Greek" (Bad Latinised phonetic spelling coming, do not have Greek keyboard) or Coinay Helion.

Until then we must work with the extreme imperfection of the spoken languages and signed languages we use to communicate.

Even when communicating through text means we are using a mirror of our spoken language.

That's true of most languages, but not of chinese / mandarin for example.

Very true. Though those languages that use a written form inspired by the ancient Phonesions do mirror in written form the spoken language.

[DavidS]

For the goal of also targeting Win32, and not having a power efficient enough x86 PC at this time, I set up ReactOS inside of Qemu on a Raspberry Pi 3B, and am surprised at how well it runs. It is almost usable, almost, still terribly slow, though a lot better than I expected.

I just need to figure out how to get sound working in ReactOS under Qemu, as speech synthesis is the project sound is kind of important.

As to the issue of portability, I am just going stick with FreeBASIC to implement the UI, as FreeBASIC targets both Win32 and armhf Linux (eg Raspbian). Much of the rest will be in C, though the UI stays in FreeBASIC.

For a C compiler I decided to stick with tcc (almost went for otcc, though it does not support enough of C for the needs) for this project.

On my shopping list for when I can afford it is a Windows 10 x86 (Atom CPU) based tablet with keyboard. So I can continue the Win32 side of development in ReactOS in Qemu using hardware CPU virtualization, and thus being much faster to work in ReactOS, then once ReactOS becomes mature enough I will be able to replace Windows 10 with ReactOS and have an acceptable x86 system.

[DavidS]

It is interesting that my experimenting shows that it is most efficient to use an external WAV player for final sound output, while having the speech synthesizer simply produce WAV for audio output.

Though I will continue to experiment, and coble something together until I have a working UI. Then focus more on the speech synth side until either I have something usable, or I have no more time left to work on it (I anticipate that I will have time to work on for at least the next 70 years, I am only 39 years of age).

[DavidS]

Would be nice to find a low cost RPi based kit to make a simple device for this application, for those that do not already have a portable device.

Unfortunately the best I can price out on putting together an RPi kit that would be completely portable comes out to over $100, while there are Atom based net-book style systems for $70. I would prefer to use an RPi kit for the purpose, simply because I would like to better support the use of the RPi.

Though it is that I am also targeting Win32 for the very reason that many already have portable Win32 based systems, and for those that do not a Win32 portable device including all needed features is the lowest cost solution.

[hippy]

I anticipate that I will have time to work on for at least the next 70 years, I am only 39 years of age.

I admire your optimism, and hope you make it. I'm not so confident in my own longevity!

[DavidS]

I anticipate that I will have time to work on for at least the next 70 years, I am only 39 years of age.

I admire your optimism, and hope you make it. I'm not so confident in my own longevity!

What could go wrong within the next 70 years. The worse thing to threaten my life in the first 39 years has been these Mini-Strokes that caused the set of problems that this thread is about, so I do not foresee anything stopping me in the next 70 years .

[DavidS]

And it seems that some force wants me to get to the Windows Dark side sooner than later. My 5 year old Android tablet just died on me today while using it to talk to the doctor of all times. So I will be ordering a Windows Tablet that I really can not afford today, and hopefully be able to get it by tomorrow.

The battery in my 5 year old Android Tablet chose today, mid conversation to melt into the board, shorting everything and eliminating its own power source. Did not cause any external damage, had to pull it open to find out what happened (well it did get a bit hot, though no external damage). Quite a way for a tablet to completely ruin itself, and a new one on me.

I had to use my super tiny Android Phone to finish the conversation at the Doctors Office.

Then there will be the cost of getting a backup Windows tablet in case anything happens to the first while I still need it to talk to people.

[DavidS]

Actually starting to get the listing means sorted in the Front end finally.

Also figured out how to move/copy an item between categories without dragging. Have a select option to move/copy then have user select destination category normal way, also allowing a means to do easy multi select by a button (as with other options, by simple button lists, that pop out of a button at the right end of each list item).

For the button icons for move and copy i am going to use a nicely styled "MV" for move, and a nicely styled "CP" for copy. With the predominance of Unix systems now, anyone should understand the meaning of that kind of icon.

On Win32 target
I got a Windows 10 based tablet ordered. So I will at least be able to use hardware level CPU virtualization in Qemu to run ReactOS for developing the Win32 target. This also gives me the ability to test the Win32 target on the current version of M$-Win32 OS (windows 10).

Of course to make sure to cover the full range, I will also have to test on Windows For Workgroups 3.11 with the Win32s extension, which will need another virtual machine, as well as on Windows NT 3.5, and Windows NT 4.0 SP3, each requiring an isolated setup in separate emulator setups.

[DavidS]

It looks like one API may be the way to go. The Win32 API. I just found out that the IoT of Winodows 10 on RPi does include audio output, and as such if I stick to a subset of the Win32 API that is common to Windows 10 IoT as well as more standard Win32 implementations I should be able to produce something useful for the RPi as well as x86 systems using a single API, and a single set of source all the way around.

This would cover a large section of potential users, as it means that most x86 Linux, BSD, Mach, and Darwin, OS's would benefit do to Wine, as well as the ability to use on ARM systems that have a Win32 API implementation (eg Windows 10 IoT) with a bit more setup work (as there is still a lot Win Iot does not have). And it will be able to run on x86 Win32 implementations as well (M$ Windows, ReactOS, etc).

[DavidS]

Perhaps it is time to rethink the touch screen, drag and drop is great for mouse based systems, not so much for touch, and then there are those of use that have lost enough of our manual dexterity that drag and drop is completely impractical.

Perhaps it is time for more applications that manage sets of data that can be organized and are able to target touch screen devices, to begin using a means of managing the order and organization of items in a similar fashion to what I am doing here (tailored to the need of the application of course).

Just a thought, I may be on a wrong track with. Though a thought none the less.

[DavidS]

I pulled out an old 8086 system, just to see how some of the old light pen stuff is done. After all the light pen is the precursor to the modern touch screen.

I find it interesting how intuitive some of the old UI's are for use with a light pen, a lot better than what we now use with touch screen, and a lot easier to navagate and otherwise deal with. There is even an on-screen keyboard TSR with my old light pen system, that works with any application that calls DOS or BIOS for keyboard input, and works well in text modes, CGA modes, and MCGA mode 13 (the computer is a PS/2, so it supports MCGA). This on screen keyboard for light pen usage is dynamic, causing the size of the most likely set of letters to be the next letter typed to increase in size of active and visible area.

Many of the UI's for light pen applications are segmented in a manner similar to what I am doing with the UI for the list items to be spoken with this Speech front end. And they are indeed easy to use.

I even had two of my friends that are both to young to have ever used a light pen interface (and neither ever did [both in mid 20's of age]), use some of the applications that are set up this way. Despite being completely different layout to anything common today they found it a lot easier than the modern stuff.

So why have we lost this obvious means of implementing user interfaces that deal with large numbers of items? Why have we moved to more difficult in the name of advancement? There really is no good reason for not having intuitive user interfaces for applications, and now with the touch screen world being as it is we really need to look at the kinds of things that have been done before, see what really makes things simpler and what makes it more difficult (and stop changing swipe to unlock directions, every couple versions, Google Android).

[DavidS]

After playing a bit with the initial design for my UI, i realized that 32 items per list is a little tight on screen space on a touch screen. So I redid things a bit to have the category lists three levels deep with 8 category tabs each, and the item list having 16 items, not so tight on touch screen space, and still very quick to navigate. This does limit the quick access saved speech items to a total of 8192 items, though that is alright, should be enough (I hope). Though with the three level category tree and 16 item display it is possible to navigate between speech items faster than you normally speak, in testing I am able to select about 20 items per minute with my limited dexterity, and as most items will have 5 words or more that makes for much better than normal speaking speed. Someone with normal dexterity should be able to exceed 60 selections per minute (one per second).

Now I need to pull the new UI, the database, and the speech synth calling parts back together. Then polish the UI a little in appearance (people tend not to use programs that they do not like the appearance of anymore). Then I will have something to show off, maybe within a week at the rate I am going, maybe.

Actually I just realized a modification that would allow for up to 8 sets of these totals, thus allowing up to 65536 without losing any speed within a set of 8192. The solution is simply to have a set of 8 buttons at the bottom of the screen to select which tab-set to use at that time, each tab-set giving 8192 items to quickly navigate, with just a momentary slow down when switching between tab sets. This is a worthwhile addition, so I will add this ability, which will be pretty simple to add at this point (just unload the current item DB and load in the one corresponding to the selected tab-set). So I will add this ability to the program, making for enough potential items to cover more than 96% of conversation without having to type.

[DavidS]

Last night and this morning I also spent a little more time playing with the available open source speech synthesizers, and I am going to just use eSpeak for the back end (until I get mine working at least), as eSpeak gives enough options to be able to produce clearly understandable speech in a consistent manner, even if the speech is a good bit mechanical sounding (with the voices I have tried thus far).

[DavidS]

I have made a little progress on getting things together today. I realized that I needed to rethink how I am doing my database a little, so I took care of that, using a linked list of structures that point to the item names in a string table, as well as to the item contents in a different string table, this is a lot faster and more sensible than using a set of pure hyperlinked text files to store the data as I was.

So hopefully sometime next week I will have something to show off, maybe something that some will actually find useful.

[DavidS]

Interesting day with the front end. Spent two hours tracking down a simple omission that caused a redraw artifact.

Still moving slowly, though at least moving in the correct direction.

[DavidS]

Well today I will get to see how well my code works once compiled for Win32. I have been doing everything thus far on Raspbian, though my new Tablet PC arrived today (the one that is replacing my old dead Android tablet). The new Tablet PC is x86 (Intel Atom), and runs Windows 10 as it's pre-installed OS (so it already has an NT with a Win32 subsystem).

[linux_author]

Last night and this morning I also spent a little more time playing with the available open source speech synthesizers, and I am going to just use eSpeak for the back end (until I get mine working at least), as eSpeak gives enough options to be able to produce clearly understandable speech in a consistent manner, even if the speech is a good bit mechanical sounding (with the voices I have tried thus far).

http://www.cstr.ed.ac.uk/projects/festival/

(dunno about ARM iterations)

willie
on the hot and humid Gulf of Mexico

[DavidS]

Last night and this morning I also spent a little more time playing with the available open source speech synthesizers, and I am going to just use eSpeak for the back end (until I get mine working at least), as eSpeak gives enough options to be able to produce clearly understandable speech in a consistent manner, even if the speech is a good bit mechanical sounding (with the voices I have tried thus far).

http://www.cstr.ed.ac.uk/projects/festival/

(dunno about ARM iterations)

willie
on the hot and humid Gulf of Mexico

Don't know about other versions, though what is available for Raspbian, Festival is very difficult to understand. It does sound smooth, though it is not clear.

[DavidS]

I now know that the WIP version of my front builds on Win32 under Windows 10 as is, and runs exactly the same on Win32 as it does in armhf Linux + X (Raspbian).

So I can continue development using my tablet, without having to worry about if it is going to run on armhf Linux (like Raspbian), as it should be no problem so long as I do not use anything that is specific to Win32 (even then could be usable, would need to add Nano-X to the build for Linux targets though).

This means that when I am board while waiting for something, no matter where I am, I can work on the front end program. This increases the potential coding and testing time, and thus reduces the over all time to something usable. This also increases the potential of spotting significant bugs before the program gets released.

The other positive in this is that the keyboard, on my windows 10 tablet, is small enough for my hands (I am a 5 foot 3 inch tall 120lb man, so the size of an average 11 or 12 year old, just a few times older). This makes typing a lot easier than with the oversize keyboards that are more common. I did not think I would ever end up with a keyboard that fit my hands well, though I have.

My typing is still slower than it should be, though having a keyboard that fits my hands does improve the situation. So it is that I should get a bit more done.

[DavidS]

Well it seems that the version of eSpeak compiled for Win32 works better and smoother than the version for armhf Linux.

Not quite sure what to make of this, though it is as it is. If anyone has any idea of why this is I am all ears (I cant talk after all).

[jamesh]

Cleared thread of offtopic, please keep on topic.