From: Rob Sacks (editor_at_realization.org)
Date: 2002-01-20 17:08:38
Dear John,
Thanks for the kind words about ElectricGuru and for
understanding my reluctance to use it for the basis for
further development.
You make some excellent suggestions. Before I respond
to them, let me say that in my opinion, the most important
thing that can be done at this stage, to make good software,
is look at existing feedback programs and use them as
starting points to design the screens and other user features
of our new software.
In other words, we should be thinking about the functional
specs from the viewpoint of the user, because they tell us
what accomodations and allowances must be built into the
program so it can do what it will eventually be required
to do. Or, to put it more simply, we should decide first
what the program will be, before we decide how to build
it. The easiest way to figure out what the program will be
is to design the interface from the standpoint of the user.
And the easiest way to make that design is by drawing
the screens and menus.
For example, do we like the method used by Waveware to
input feedback protocols? Can we design something
better? Etc.
Somebody may be tempted to object at this point: but
we don't have to plan carefully, because we will make
the software so it can be modified and extended. To
which I reply: yes, of course we will do everything
possible to write software that can be modified in
the future as easily as possible, but this is not a substitute
for planning as thoroughly as possible in advance. In
fact, the two things go together. The best way to promote
maximum future extensibility, is to define the
future needs as concretely as possible in advance.
One of our members here volunteered last year to
coordinate a project to solicit comments about the user
interface from experienced feedback practioners, but
if anything has come of that yet, I'm not aware of it.
I'm a great believer in the crayon school of
spec'ing: draw the screens and menus.
> We make the software modular. This way we can link in
> whatever "Modules" are required for a particular
> purpose. .... ECG's and such have already been discussed
> so why not allow for that in the software.
I agree that this should be our goal. It is also our most
difficult design problem. How can we make a program
that allows other programmers, in the future, to take
the source code and add new types of machines to it?
It's a difficult problem because when somebody adds a new
type of machine, he or she will have to add new code for
every single functional machine-specific part of the
program.
For example, with an EEG machine, the program has (more
or less) the following functional parts:
-- allow the user to edit and save protocols
-- parse the incoming data as it arrives at a port
-- decompose the signal with FFT and/or digital filters
-- display the decomposed data with graphs
-- compare the decomposed data to the threshholds in the protocol
-- generate reward signals (including fancy displays like games).
Now let's suppose, after the EEG part of the program
is complete, that somebody wants to add support for
an ECG machine. Every single part of my functional
breakdown (except the last) has to be changed.
In other words, there's no easy or natural way to divide this
program into modules that allows additional modules to
be *added* when new types of machines are added. Instead,
pre-existing modules will need to be modified. Or the
equivalent of a whole new program must be added. If you
have to add a whole second set of everything I just specified,
in what sense are you modifying anything? You're not
modifying anything; you're writing a second program. (Of
course if the two machines communicate simultaneously
through the same port, the port-reading code has to be
integral, and some low-level code like the FFT routines
can service both the original code and the new code,
but these two things are a small portion of the program,
and the significance of the first one is that it cannot be
done in a modular way.)
Alternatively, the program could be written as a sort of
interpreter that allows support for new machines to be
specified in a sort of program-specific data format. This
second suggestion would be quite technically demanding
and probably not worth the effort.
If somebody can think of an easy or natural way to divide
this type of program into modules that allow new types of
machines to be easily added, I'd like to hear it. I've been
thinking about this for a year now without much success.
> We can change the interface to the EEG without
> interfering with the rest of the software.
I think it goes without saying that a program of this type
should have drivers (I'm using the word driver loosely)
so it can work with any EEG machine on the market with
the addition of a tiny amount of code. Presumably, the
only reason why existing commercials programs do not
work this way is business. Manufacturers restrict their
programs to their own hardware to promote hardware
sales, just as Apple has never ported the Apple OS to
other hardware. But we can't do this, even if we want to,
because we are going to write open source, and anybody
will be able to adapt the code to new machines if they
want to.
To show how easy this is, ElectricGuru works with 3
EEG machines and it takes maybe 30 minutes to add
a new one. Adding a new machine requires only
a few dozen lines of code. This is so trivial and easy
that I don't think we need to discuss it here.
(By the way, if we write a good program, it will
not "belong" to the hardware designed by this group,
any more than Linux belongs to any particular brand
of computer.)
> Anyone can added their own modules to the user interface
It's useful to examine the way that this is currently
implemented by Brainmaster. Brainmaster publishes
a DLL that is a sort of mathematical server. The DLL
parses the incoming data from the EEG machine,
decomposes it with FFT and filters, and makes it available
to the user program. The user then writes everything else.
This would be easy for us to imitate. But does it allow
the user to add a module to the existing interface? No; it
allows the user to write a whole separate interface.
If we examine the interface of an existing program such as
Waveware (particularly the protocol-design screens) it
becomes apparent that it's really rather difficult to allow
a user to *add* something to an *existing* interface.
The one thing that *is* easy to add is the *reward*
portion of the interface... the sounds that the user
listens to, or the game that the user plays, etc. But
precisely because this is easy to do, we don't have
to worry about it too much.
(I keep stressing the protocol-input screens because they
embody the whole functionality of the program. Can
The user train on phase coherence or on reduced
variance? Does a successful epoch affect something in
a game or does it play a major chord from an oboe?
All this is implied and embodied in the protocol-input
screens.)
> How about a user program that Bi-audio sounds
> that response to your current brain waves?
Sure.
> Or flash the screen (like ElectricGuru) to stimulate brain waves?
When I wrote ElectricGuru, a tester asked me to add
de-synchronizing strobe flashes to imitate the Roshi.
We only tested a very primitive
version but it seemed to work. I think that sort of thing
could probably be taken further under Windows, contrary
to what many people imagine.
> Use JAVA for the output and user interfaces.
If anybody wants to write Java, great, go ahead.
Personally, I'm only interested in writing software
that is as excellent as possible from the standpoint
of the user. To me, the user is God. That means
I want maximum artistic control and speed, and
I want to write a program that can be used by as
many people as possible.
That leads me to the usual tools used by most
commercial publishers: C++, native code, the
most widely-used operating system, etc. Bottom line:
if I write more code of this kind, I prefer to write
in C++ for Windows and DirectX. Of
course every module that can be portable, should
be made portable.
I'm not saying this is right and Java is
wrong; it's what I would want to do personally.
If anybody else wants to write in Java, that's
fine, I wouldn't try to discourage them.
Best regards,
Rob
--------Original Message-------------------------
> From: "John Morrison" <jmorrison_at_ahc.net.au>
> Date: Sun Jan 20, 2002 9:21 am
> Subject: RE: [buildcheapeeg] Software (was ElectricGuru)
> G'Day
> I'm a very new to this group so I've been lurking for a few days but now I'd
> like to throw my 2c worth into the mix...
This archive was generated by hypermail 2.1.4 : 2002-07-27 12:28:36 BST