From: Dave (dfisher_at_pophost.com)
Date: 2002-03-06 04:29:23
Strange; I have sent a couple of messages to the group earlier today, but only
the last one just showed. I know that Yahoo was (is?) having maintenance woes,
but since other messages are appearing, I am resending at least this one since
it is somewhat relevant to the current conversation. Jim-M, I can understand
your frustration, but I also see a lot more progress being made lately in terms
of concrete direction and interest in the OpenEEG project. We all hold very
important pieces to this puzzle, and it is a marvelous opportunity to work
together. Step by step...
Dave.
==================BEGIN FORWARDED MESSAGE==================
n Mon, 04 Mar 2002 15:16:49 -0600, Doug Sutherland wrote:
>bios level disk access these days. All of these other EEG
>programs like Brainmaster, Biograph, and countless others are
>using OS level services. If you need to go into single tasking
>mode for speed, then maybe the program is not architected very
>well, by today's standards. There are ways to force windows
>into single tasking (booting only at DOS level), and there
>are ways to do the same in linux, but most people won't be
>very happy with that. Before we argue any further on this I
>suggest that we try it. There is only one way to find out
>for sure, verytical prototyping.
I've been playing around with just this very thing today. Right now I've got
classes set up that are reading the data stream coming from the ProComp (serial
port version, they have a USB one in the works) and splitting that stream into
separate sensor-specific streams. Then, I've got a handler thread for each
stream which provides access to the data for one or more connections. Right
now the data is just being pumped to the console (no FFT processing or any
other filters), but I had eight simultaneous connections going without data
loss. Well, actually, there always does seem to be one minor hit right when I
turn the ProComp on. I find the sync, lose it about two seconds later, and
then get it back again and then all is fine. I'm not sure if that is related
to the ProComp or the serial interface yet. And I still have some concerns,
especially once we have more things going on (sound processing, protocol
engines, and whatnot). Hmmmmm.... I'll have to start up a bunch of apps and
then try test program. I'm almost afraid to try because I don't want bad news
at this point! ;-)
And I know that the way I am doing this is not exactly the way that has been
disussed here, but it was the approach I laid out late last year and I want to
finish testing the theories before changing direction. Also, in deference to
MS Windows (and, oh, how it pains me to do this), I have been ripping out Linux
specific code in favor of cross-platform solutions. There are still two
sections which will need to be changed -- my use of select() (MS Windows, in
their inifinite and mysterious wisdom only designed it to work with sockets,
and not with other file descriptors, so I'll have to use something like
WaitForMultipleObjects() for Win32) and my use of unix local sockets. The
latter I am gonig to abstract out so that I can use them over on Linux, and use
something less flexible in the Window's world, like pipes. That way I get to
have my cake and eat it too. :)
>There are countless EEG apps that are NOT using bios level
>disk access and are NOT operating in single tasking mode.
>
>> Dave tells me that he cannot use the FFT waterfall display
>> supplied with his EEG machine because it is way too slow.
It is very slow. They even mention in the manual that it is for analysis use
only, as it is not suitable for real-time display. However, I think this is
because of poor design rather than anything inherent in the waterfall display.
Jim-M's DOS program is a testament to that. BioGraph is a splendid piece of
software as far as features and capabilities are concerned, but it also has the
feel of a software package that was evolved rather than planned. It is like
prototype which made it to market, never to be rewritten. Thus, the UI is
clumsy, and it is very easy to misunderstand how to accomplish simple tasks.
For example, in order to produce the ASCII dump of the data that I used for
Jim-P's BWView program, I had to load a biofeedback screen, which then let me
load previously recorded session data, which then enabled the File->Export
option.
Why did I have to load a biofeedback screen? It has nothing to do with the way
I wanted to use the data, and yet I can tell that this is where the
programmer/analyst must have started -- wanting to create a program that would
use sound and visual animations for biofeedback. Thus, all other "views" to
the data and session exist under that umbrella.
And yet the program does an incredible amount; it is just unnessarily
complicated and poorly laid out.
Anyway, I am juggling a couple of different activities this week, but I hope to
have what I've been working on done next week for people to play with. It
might help stimulate some more ideas in terms of design and approach -- and
help figure out just what will, and what will not, work. I also want to put a
GUI on it to make it purtty. :)
Dave.
===================END FORWARDED MESSAGE===================
This archive was generated by hypermail 2.1.4 : 2002-07-27 12:28:39 BST