Hi folks, Yet another opinion piece on recent messages (and sorry for tech language here): If I'm asked to define one trait of humans that machines don't have, it'll be "inventive mindset." First, inventions are manifestations of solution to a problem, such as airplanes (to get to other side of the world quickly). Second, inventions allows more efficient solutions to be found later (if not now). in connection with what we've discussed for the past few days, I'd like to present some facts and opinions on "KeySoft-related inventions" that are possible, could be made possible or impossible. So what defines "possibility" from computer users's perspective? To some, it could mean using newest hardware out of the box; to others, it could mean solving complicated math problems on a computer; to others, it could mean finding solutions to weather predictions with 100% accuracy. But these are sort of "could be possible" scenarios - the new hardware may require installation of a driver, not all computers can solve all math problems easily and weather predictions could go wrong. To those who work in software industry, it usually means whether a computer can solve general and specific problems using availible resources, and how do we do it so we can take advantage of availible hardware. For instance, suppose we wish to find the largest file (one file only) from thousands of files. We could do something like, "build a database of file sizes, then do some work so that we can see the largest file size at the beginning of our list." (a generalized formula of sorting.) Or we can do something like, "compare two files; if the first is larger than the second, then the first is larger; if not, the second is larger; keep comparing adjacent files and update the largest value; when finished, grab the largest file size from the list of files." (a specific mode of sorting known as "comparison sort".) These two approaches have advantages and disadvantages: while the first one allows adopting the database for sorting other things, it requires extra space for storing the database itself, and if coded wrong, it'll take a long time to do it. The second one, although it doesn't use a lot of memory, comparing thousands of files can take a long time. And these two modes of operation have common flaws: what if there are two files with identical sizes when we wish to find one large file, or if the file count is empty? In the first case, we'll get erronious results, and in the second case, we've wasted valuable CPU time. Or let's take our VOIP (Voice over IP, or voice chatting) scenario. Suppose we did have voice chatting feature that runs well (hypothetically, that is). It uses say, 20 MB of RAM (memory) just for having high-quality voice calls between two people using external microphones with vast Internet connection. Now we with to add another person to our conversation, and this person uses an external mic but has slow connection. What would be the performance of our service? Not that good, right? Now let's say another person wishes to join from her college wireless network (a very fast connection), but she uses the internal microphone. From the current position, it works quite okay between three people, but at her end, she would feel a bit anoyed when she finds that the voice quality has gone down somewhat. And after using this voice chat service (with four people), she finds her Apex quite unresponsive due to the fact that Apex used 30 MB of RAM for voice chatting conversation with four people. So what should we do to rectify this situation? Should we tell people to use fast Internet connection? No, because there are parts of the world which doesn't have fast connection speeds. Or should we tell people to use external mics? Unlikely to work because of finances. Or how about switching to a different synthesizer when doing voice chatting? That could increase confusion (it's the virtual memory problem all over again). Or should we use some client which use less memory but has good voice quality? Not yet, because good voice quality means using more RAM to process your voice data - more towards compressing high-quality audio. As the picture demonstrates, when these kinds of "memory intensive" applications are designed, we need to take into account the availible resources of the hardware which it'll run on. Thus, as for the time being, I'd like to say that, unfortunately, voice chatting is something that requires more research (to be classified as "could be possible" if memory is managed efficiently) i.e. not now, but perhaps later. So what other things are possible or impossible? Some few scenarios: * Possible: SDK (requires devotion to it for a while), more file format support (given if someone finds a good doc reader or converter program), more screen reader support (if the driver is written) and so forth which utilizes current hardware. * Could be possible: voice chatting (if we could find anything that runs well and satisfies a number of requirements, but the hinderences are mic, RAM usage and Internet connectivity issues), more USB hardware support (if we can find anything that works well), larger storage cards (a possible firmware upgrade is needed) and so forth which requires research and thinking about hardware resources. * Impossible: speech recognition (what you might have been calling "voice recognition" is actually "speech recognition" because of variability in a person's speech characteristics and time and memory required to process your voice to text (concerned with accuracy and performance; imagine transforming your voice dictation to braille documents - BrailleNote would scream for air after the process)), more power to USB ports (a USB hub (or a port) can supply limited power to a device; having more ports increases strain on availible power for USB hardware, thus our conclusion that hard disks require two ports when connecting to Apex), FM radio recording on apex (because of hardware) and other things which involves deep-level diplomacy between software, system programs and hardware (and it gets messy if not done right). As for Microsoft abandoning Windows CE, let's ponder this for a while: if you know which CE versions Windows Phone 7 is based on, then you'll realize the impact of the rumors. Just to give you a hint: part of Windows Phone 7 is based on the version that Apex has. I think that statement about MS abandoning CE might have came from the fact that Windows 8 will run on mobile tablets (because the software and hardware specs of tablets has reached or on par with netbooks; we have dual-core or quad-core processors on cell phones (the current notetakers or ones which will be released (which are based on Windows CE) does not have dual or quad core processors because the oS itself doesn't support them unless 7.0 is used); the next revolution would be 64-bit cell phones with 4 GB or more of RAM). I hope this helps someone out there, and sorry for some difficult words and concepts. Cheers, Joseph
___ Replies to this message will go directly to the sender. If your reply would be useful to the list, please send a copy to the list as well. To leave the BrailleNote list, send a blank message to [email protected] To view the list archives or change your preferences, visit http://list.humanware.com/mailman/listinfo/braillenote
