From: Rob Sacks (editor_at_realization.org)
Date: 2002-01-21 14:17:44
Howdy John,
> Don't you just hate getting Dear John letters. :-)
I must be incredibly lucky -- I've never gotten one! :)
> I've written QUICK programs before and I"D HATE
> anyone to actually see them.
> :-)
lol. yup. :)
> I agree how about we start a new thread and ask WHAT
> people want the software to do.
Sounds great. I think it would be most productive
to do that on one of the neurofeedback lists instead of
here. That's where the folks hang out who actually use
these machines and programs day in and day out. They
know everything about protocols and can compare the
existing systems in minute detail.
If I were doing this, I would go to one of those lists (maybe
Biofeedback_at_yahoogroups.com or PsyPhy
LISTSERV_at_L... but I haven't been
following those lists lately so not sure which would be best)
and announce that the OpenEEG project is now designing a new
program that will be distributed free, like Linux, for
many (and eventually most) EEG machines. I would ask
the dozens (hundreds even) of experienced neurofeedback
practitioners on that list to help decide what the program should
do exactly. The resulting thread would be chock full of expert
advice, I think. Those folks can also tell you which existing
program has the best screens for any particular function that's
currently available. They can mail you screen shots too.
The way to keep the thread on target, I think, is to keep asking
for examples of which protocols the program should be able
to implement. This area is way more complicated than "boost my
alpha." There are virtual channels, various ways of
looking at phase, reduced variance, autocalculated
dynamic thresholds, all kinds of stuff.
> I'm not real familiar with what is out there so maybe a list
> of links would help us.
The best single place to find links is probably
Rob Kall's website www.futurehealth.org. He runs
the main annual industry convention. He would be a good
person to ask for advice, too. (He may see this.)
Good advice about synchronizing the feedback with
entrainment effects (lights, binaural beats, etc.) can be
obtained from the mind-l_at_yahoogroups.com list.
Your three-part design sounds good. Here's what I
suggest we do to start fleshing it out:
1. Make a list of possible protocols. This is really
the guts of the program functionally.
2. See if we can design the stage-2 routines for
all types of machines so they have a common
interface internally to the rest of the program. For
example, when I wrote ElectricGuru, the equivalent
of your stage-2 made a routine available to the
rest of the program:
get_magnitude ( channel, start_frequency, end_frequency )
My question is, can we define a small set of functions
of that type which would be exactly the same across
all the stage 2 modules and which would enable us to
implement all the desired protocols?
(In practice the example function has to take into
account the fact that we may be implementing
digital-filter-coefficients on the fly for desired
frequency ranges.)
> - Digital triggers could be placed here too. (i.e.
> a module that will send
> a signal back when a certain wave form is present)
This is the logic that tests whether the reward
conditions that are specified by the protocol are
met. Again -- i cannot emphasize this enough -- I think
we should focus our attention here for design purposes.
This is the heart of the program, I think (at least
functionally).
A very big part of your stage 3 will have to be
concerned with allowing the user to define these
"triggers" (maybe we should call them "targets"
and let's call a collection of targets a "protocol".)
When I wrote ElectricGuru, it quickly became
apparent that protocols can be so complicated that
I was tempted to make a script language (to be
used by the user) to define them.
The whole protocol stuff straddles your stage
2 and 3: In your stage 3, the user defines protocols
and edits them; in stage 2, the targets are tested
against the signal. I'm not sure this is the best
way to handle this.
> This (stage 3) would be where it's all tied together. It chooses
> the input, the processing to be done and how to display it.
> Which should be very easy with
> well defined interfaces.
Traditionally, this type of program has two types of
interface. One is used by the operator (in a clinical
setting, the clinician) to set the protocols and control
the session parameters.
The other interface is the thing that provides the reward
signals to the person wearing the electrodes. Today this
is often a computer game.
I think we should split these two interfaces into two
parts because they are quite different from a programming
point of view.
The user-interface is just a tremendously fancy way of
answering a yes or no question which basically boils
down to, "Given the protocol and brain state, are the
electrodes currently reporting that the reward conditions
are met?"
I'm exaggerating slightly because the question might
be a percentage instead of yes-no. For example, the
reward signal might be a pie chart representing
a number between one and a hundred. And the interface
may show the answers to several questions at once
instead of a single one.
But basically, my point is that the user-interface is
almost completely
insulated from the rest of the program. It's inherently
totally modularized. It raises no design issues. We
don't have to worry about it now. Somebody could write
that part of the program right now without knowing
anything at all about the rest of it.
The operator-interface is very different because it's
intimately entangled with the whole rest of the
program. We can't even begin to write it until we
know everything about the rest of the program.
> It's the tying together that I'm looking for. A new TYPE of device will
> require additions in all 3 layers but after that new user interfaces or
> devices of the same sort can be added with minimal or no changes to the
> other layers.
Yep. I think you're right. I've been hoping to figure out
some way to allow plug-ins for new machines that require
no changes to existing code, but it's not going to happen.
> Why I say Java should be considered is that it is portable
> with out recompiling. There are a lot of Linux users out
> there and it is growing.
> If we ignore them I believe it would be a mistake.
> Also as Linux runs on low end platforms the experimenters
> out there could set up an old 486 as there "MIND MACHINE"
> with the software instead of there main machine.
> Lastly it is an easier language to understand an program in
> so we would be
> allowing access to the system for more users.
Yep. I can't argue with you. Those are the advantages of
Java (or, to some extent, a cross-platform C library).
We both know the tradeoffs.
I guess it boils down to taste: what would be fun?
For me, it would be more fun to write the best possible
commercial-quality program for users (users in the
sense of consumers) that would blow the socks off
the multi-thousand-dollar commercial programs.
For me, it wouldn't be much fun to write a program
for hobbyists and users of 486 machines. There's
nothing logical about this preference; it's like
preferring swimming to hiking. And to be perfectly
blunt, I'm willing to overlook Linux users for the
same reason that commercial publishers usually
overlook them. (Same thing for Mac.)
However, my opinion probably doesn't matter very
much, because probably I'm not going to be our
Linus Torvalds -- I'm not going to be the person who sits
down and writes the core of this program and gets
this project off the ground.
If you want to be that person, then you should probably
write the core of this thing any way you want, and
other folks will presumably jump in and help you.
Gotta do what's fun! :)
Best regards,
Rob
----- Original Message -----
From: "John Morrison" <jmorrison_at_ahc.net.au>
To: <buildcheapeeg_at_yahoogroups.com>
Sent: Monday, January 21, 2002 4:13 AM
Subject: RE: [buildcheapeeg] RE: Software (was ElectricGuru)
> Don't you just hate getting Dear John letters. :-) .......
This archive was generated by hypermail 2.1.4 : 2002-07-27 12:28:36 BST