From: John Morrison (jmorrison_at_ahc.net.au)
Date: 2002-02-27 06:39:44
> >I am completely open to ideas for the project.
> >My personal C++ skills are rusty
>
> .. while your C++ skills are rusty, my Java skills are nonexistent. :) My
> background is in C, then in C++, and while I thought about moving
> into Java, did not have any pressing need to do so.
University forced me into Java but I do like it now. :-)
> >So I thought that if there was a chance of completing this project I'd
have
> >to leave it in an area where I didn't' have to rely on others to do all
the
> >work. If I have a group of people that were willing to implement/discuss
> >the design I'd be quite willing to use what ever they chose!
>
> I understand that, and I would be at a crossroads myself if the
> group decided
> to use Java as the primary language for the project. It may very
> well be that
> Java offers the performance necessary for this project and might
> even make more
> sense given platform independence. But if your C++ skills are
> not *too* rusty,
> I would advocate that course. Would you be willing to work on
> implementation
> if it is in C++? If you are working in Java, I gather that you have a
wealth
> of expertise in object oriented methods which would be invaluable.
I wouldn't say I have a wealth but I do try. :-)
YES I would be willing to work on it.
I believe in the concept of a modular system and will work on it whatever is
decided by the community.
I can't do it by myself!
> >> From previous threads, C++ seemed to be the prevailing choice.
>
> >Yes there are a lot of C++ programmers on here but are any of
> you willing to
> >implement the design I've out lined?
>
> Well, I think that would depend on the nature of the application that this
> group needs most, and that is still very unclear here. So far I get the
sense
> that OpenEEG has attracted several NF/biofeedback enthusiasts (such as
myself),
That is my base interest to!!
> but that we all have different interests and intentions. What this means
is
> that whatever we develop will at best be a playground for prototyping.
We'll
The Modular design means that is EASY to prototype but is good for the final
product!
> learn a lot, we'll make a lot of changes to the source code, reconsider
our
The base "Protocol program" once it's settled wont' have to be changed at
all.
You simply write/modify modules to do the task you require.
> design and approach, but what we end up with may not be what we
> need (in order to promote cheap EEG devices). Or, it might just define
that
> focus. I don't know, because the audience for OpenEEG seems to waver
between the
> enthusiasts and the professional biofeedback practitioners (which do not
have
> an adequate presence here yet).
Yes as Rob keeps saying we need professional input!!!
But if we have a flexible frame work to plug new modules into then it's easy
to add to later.
SO we what ever the user wants he can produce from a full on medical system
to a hobbyist system!
> I, however, would love to work on this project with others. I have
already
> been fooling around with data acquisition classes under Linux, and have
the
> framework put together for a client/server based interface. If I come
here to
> work, my sense is that I will have to abandon this approach, because it
relies
> on Linux's rich IPC environment. However, I don't do Windows. Nope, just
> won't. :) But in order to benefit this group, I think a Windows version
will
> be necessary because the people who are most apt to use this in
professional
> circles will all have MS Windows on their machines, so I will work toward
> cross-platform independence.
I think cross-platform is the only way to go. It'll give the software
longer life, as we wont' be tied to one platform.
THIS DOESN'T eliminate the possibility of modules being written for a
particular platform.
IE Video output may have to be written for direct X for windows and
something else for Linux.
As long as the framework is cross platform all it means is that a particular
module will have a smaller audience!
> So I need to know that I will be able to
> (1) actively work and help maintain code,
First step is to get the design hammered out.
After that the code can be broken down to the parts that we are best at!
> (2) provide a framework and/or biofeedback library I can use for PIES,
I think PIES and "NF Frame" will work hand in hand.
The BF library will be great for the Module writers and of course we will
need methods to hook into the frame work.
> and
> (3) run it under Linux to reap the many rewards and benefits there.
That is the aim of the game. :-)
Maybe
> With that in place, you have me, heart and soul. :-) I'll need more
> detail on how you envision the plug-in approach you advocate working (what
is
> the nature of the hooks that will define the plug-in, how is information
passed between
> plug-in and engine, plug-in to plug-in?, etc.), but otherwise I think it
is a
> very workable design. It's going to be complicated in order to support
> multiple devices, but I think the reward will be worth the effort.
Shouldn't be that complicated to support multiple devices.
1. Write a module to communicate between the device and the framework.
2. Cross Compile
3. Use
> So... with that in mind, I like the idea of starting with a simple
monitor.
> Put together the framework, but focus on one very simple implementation of
that
> framework -- say, a simple line graph display of EEG data, or if you want
to
> add filters, a mind-mirror like display.
Sounds good!
The steps as I see it
1. Designate the module brake up of the system.
(eg Hardware-Filters-monitor)
2. Decide on the interface requirements of the modules
(This will be the job of the framework!)
3. Build the libraries for the modules
(This way the modules can be built, even if we just have dummy methods at
the start)
4. Start construction of the modules
(This will probably be an individual effort for each module)
5. Build frame work to load and connect modules.
(Lots of thought needed first!)
6. Start testing/Using
7. Try it out on some of the professional NF people/doctors and see what
needs to be changed for them!
> This will flex the muscles of all the
> various stages that have been talked about here (data
> acquisition, processing,
> and display) and see how well the framework holds up, or if we
> need to go back to the drawing board.
YEP and we probably will revisit AT LEAST some of the decisions we've made!
> Dave.
John
This archive was generated by hypermail 2.1.4 : 2002-07-27 12:28:38 BST