OpenEEG - EEG hardware and software

This doesn't just apply to OpenEEG or open source development.  The 
majority of  software projects that are started are never completed.  
This applies to commercial software, business contracts, even government 
contracts.  It's a huge problem, and a lot of people think it will be 
solved by the open source movement.

Ian Vincent wrote:

> Hi there and Why? there
>
> I know it is a very childish thing to ask 'why', but I am going to ask 
> anyway because I simply don't understand. I hope no one takes this as 
> a personal criticism, they are only my comments, and thoughts around 
> software.
>
> Why is it that this project has had numerous attempts at software 
> projects that seem to get started and then go so far, then stop. Is it 
> a feature of software authoring, that the author gets bored or 
> distracted and moves onto other projects.
>
> Or is it that the Author under estimates the time it takes, and 
> eventually other priorities crop up.
>
> Or is it that its so damn complex that the author gets lost.
>
> Or is it that the Author loses interest.
>
> Or is it something else all together.
>
> Or is it that Software is endless in itself.
>
> Being a hardware guy, I used to envy software guys because of their 
> ability to work together collaboratively over the internet, sharing 
> code and ideas, etc. I thought this was something that Hardware guys 
> couldn't actually do. But the evidence from this OpenEEG project is 
> just the opposite to what I used to think. The Hardware seems to 
> evolve spontaneously, with intense levels of interest, and the posting 
> back and forward of spice models and text and PCB designs, and out of 
> the end pops a proffesional PCB that does the job.
>
> So what's happening with the software. Is it more difficult to work 
> collaboratively. Are there so many variables and combinations and 
> permutations that it gets sidetracked or what. I don't recall any 
> details of the inner workings of the various project softwares posted 
> here. No plans or sketches or models or flow diagrams or such. So how 
> would there ever be collaboration if there is nothing of this nature. 
> I have seen some code that I don't understand because I don't do code, 
> so cant use. I also have BioExplorer that I can't see the code but can 
> use. As an Opensource project we need installable code that actually 
> does something, yet has opensource.  It seems to be about how to 
> define what the 'does something' actually is, before the coding 
> starts, perhaps.
>
> How an we improve this situation. What is the norm for collaborative 
> software development. Are there tools out there for use in this area, 
> or are these tools so complex that they become there own project.
>
> What I think is needed is a fresh start, a new approach, an over all 
> plan, a collaborative software project. Now that we have a reliable 
> and stable hardware platform, ie modEEG,  this is possible. It opens 
> the gate to software developers and we might now see some sustained 
> progress. I am sure in the past the sheer time involved in getting a 
> EEG device functioning provided enough alligators to ever prevent the 
> swamp being cleared.
>
> How do we do this guys. How can I help. How can we keep this flexible, 
> and open, and evolving into the future. How do we guaruntee that the 
> project will end up with a working software at the end of all of this.
>
> What happened to the object library.?? and where is it defined. Can it 
> be used or is it old and crusty.
>
> Ian
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: SF.net Giveback Program.
> Does SourceForge.net help you be more productive?  Does it
> help you create better code?  SHARE THE LOVE, and help us help
> YOU!  Click Here: http://sourceforge.net/donate/
> _______________________________________________
> Openeeg-list mailing list
> Openeeg-list@...
> https://lists.sourceforge.net/lists/listinfo/openeeg-list
> Go to the above address to change your
> subscription options, e.g unsubscribe.
>

At 09:02 PM 12/12/2003 -0700, you wrote:
>This doesn't just apply to OpenEEG or open source development.  The 
>majority of  software projects that are started are never completed.
>This applies to commercial software, business contracts, even government 
>contracts.  It's a huge problem, and a lot of people think it will be 
>solved by the open source movement.

Jeremy

What you and David say makes the situation more real to me and I think we 
need to address it with some kind of solution, whatever that maybe. I have 
studied a little software (oop) design theory but the deeper I dug the more 
complex it got, so eventually I abandoned it, simply because I don't have 
the expertise to understand it. Things like case tools and such exist for 
use in these situations but imo are far to formal for practical use in a 
group situation like we have here. My gut feeling on this is that as a 
practical group of creative engineering folk we should be able to engineer 
our way around this problem, but we may need to step out of the normal 
design paradigm and come up with some new ideas and approaches. I for one 
would like to try.

You put out a call for ideas for an NFB app that you proposed to build and 
this has to be the place to start. But where would such ideas collect. How 
would they refine themselves into a cohesive model from which an 
application could be built. How would they be presented to the group so 
that others can follow what is evolving, and provide new input. How could 
we categorise such ideas in terms of priority. The point I am making is 
that before we have any ideas on the 'table' we should think about what the 
'table' actually is.

I could send you ideas, but where would they end up. Initially as emails in 
your email box, as scattered text, some via the list, some via back 
channel. No one would know what was happening except those that are privy 
to the correspondence. I have seen this already, many times, and so 
recognise its potential to derail the exercise mid flight.

Looking at it from the point of view of 'collaboration', the OpenEEG 
project is a collaboration of technical people, but is also a collaboration 
of hardware and software and now users, both in terms of trainees and their 
supervisors. Each of us has our own specialty and our own opinion and our 
own ideas, so things can get very very complex, very very quickly. How to 
control this complexity is the big question. However I think it is doable.

Perhaps we could start by developing a set of statements that define the 
objectives of this collaboration and of the software that can be the result 
of it. From what I have seen of Object based design, the Objects themselves 
should closely mimic the natural reality of the problem that is being 
solved, so that in formally stating the problem you also state the roots of 
the infrastructure that becomes the solution, ie the design for the objects 
themselves.

As I understand it, Objects can present external interfaces through which 
other objects can communicate and that such an Object can be built using a 
variety of technologies and will still function, since all that external 
object see is the interface that the object presents, and not its internal 
workings. I see a parallel with this conceptual idea in the hardware design 
where various integrated circuits can be used to substitute a particular 
performance aspect to the overall unit. Each IC is defined by is own data 
sheet which defines its inputs and outputs, its internal block diagram, and 
can be from many and various vendors, using a range of physical 
technologies. It is this idea that I suggest that we could attempt to 
emulate. Somehow.

Each block could be worked on by seperate people perhaps, and it is 
probable that some of the blocks already exist, in core form at least. Like 
Jim Peters work with filters obviously form the core for the filters that 
we need, but may need packaging into an 'Filter' object of some sort, yet 
to be defined. This is a good example since it demonstrates my point. What 
inputs would such a 'Filter' object require and what outputs would it 
provide. Obviously such a 'Filter' object needs inputs of frequency range 
and a data source and has output of filtered data and power/amplitude, but 
there could be others. We need to look at what services the user would 
require of such an object, and work from there.

The question that I am seeing is how to define the Object, not necesarily 
what it actually is, because that is defined eventually by the code itself, 
but what it looks like to those that use it, both in terms of the other 
objects that will provide input to it and receive output from it, but also 
how it will look to the user when they are doing NFB, or the supervisor who 
will configure the filter for the specific purpose.

I would like to suggest that we work toward a set of html pages which 
define the various blocks and objects that make up the overall application, 
with a master html that defines the app in its entirety. For now we need a 
page that defines the 'objectives and features' that the app will include. 
Effectively this 'objectives and features' page could be the initial 
collection point for the various ideas that folk will come up with. Such a 
set of pages becomes a site where the overall app is defined, but with 
seperate pages for each Object. Obviously the application itself is the 
central object.

I have some ideas that I am working on for graphical presentation of 
complex object sets, so this could be useful.

I'm just thinking out loud here. Is this doable or not. ??

Ian

On Sun, 2003-12-14 at 02:51, Ian Vincent wrote:
> What you and David say makes the situation more real to me and I think we 
> need to address it with some kind of solution, whatever that maybe. I have 
> studied a little software (oop) design theory but the deeper I dug the more 
> complex it got, so eventually I abandoned it, simply because I don't have 
> the expertise to understand it. Things like case tools and such exist for 
> use in these situations but imo are far to formal for practical use in a 
> group situation like we have here. My gut feeling on this is that as a 
> practical group of creative engineering folk we should be able to engineer 
> our way around this problem, but we may need to step out of the normal 
> design paradigm and come up with some new ideas and approaches. I for one 
> would like to try.
> 
> You put out a call for ideas for an NFB app that you proposed to build and 
> this has to be the place to start. But where would such ideas collect. How 
> would they refine themselves into a cohesive model from which an 
> application could be built. How would they be presented to the group so 
> that others can follow what is evolving, and provide new input. How could 
> we categorise such ideas in terms of priority. The point I am making is 
> that before we have any ideas on the 'table' we should think about what the 
> 'table' actually is.
> 
> I could send you ideas, but where would they end up. Initially as emails in 
> your email box, as scattered text, some via the list, some via back 
> channel. No one would know what was happening except those that are privy 
> to the correspondence. I have seen this already, many times, and so 
> recognise its potential to derail the exercise mid flight.
> 
> Looking at it from the point of view of 'collaboration', the OpenEEG 
> project is a collaboration of technical people, but is also a collaboration 
> of hardware and software and now users, both in terms of trainees and their 
> supervisors. Each of us has our own specialty and our own opinion and our 
> own ideas, so things can get very very complex, very very quickly. How to 
> control this complexity is the big question. However I think it is doable.
> 
> Perhaps we could start by developing a set of statements that define the 
> objectives of this collaboration and of the software that can be the result 
> of it. From what I have seen of Object based design, the Objects themselves 
> should closely mimic the natural reality of the problem that is being 
> solved, so that in formally stating the problem you also state the roots of 
> the infrastructure that becomes the solution, ie the design for the objects 
> themselves.
> 
> As I understand it, Objects can present external interfaces through which 
> other objects can communicate and that such an Object can be built using a 
> variety of technologies and will still function, since all that external 
> object see is the interface that the object presents, and not its internal 
> workings. I see a parallel with this conceptual idea in the hardware design 
> where various integrated circuits can be used to substitute a particular 
> performance aspect to the overall unit. Each IC is defined by is own data 
> sheet which defines its inputs and outputs, its internal block diagram, and 
> can be from many and various vendors, using a range of physical 
> technologies. It is this idea that I suggest that we could attempt to 
> emulate. Somehow.
> 
> Each block could be worked on by seperate people perhaps, and it is 
> probable that some of the blocks already exist, in core form at least. Like 
> Jim Peters work with filters obviously form the core for the filters that 
> we need, but may need packaging into an 'Filter' object of some sort, yet 
> to be defined. This is a good example since it demonstrates my point. What 
> inputs would such a 'Filter' object require and what outputs would it 
> provide. Obviously such a 'Filter' object needs inputs of frequency range 
> and a data source and has output of filtered data and power/amplitude, but 
> there could be others. We need to look at what services the user would 
> require of such an object, and work from there.
> 
> The question that I am seeing is how to define the Object, not necesarily 
> what it actually is, because that is defined eventually by the code itself, 
> but what it looks like to those that use it, both in terms of the other 
> objects that will provide input to it and receive output from it, but also 
> how it will look to the user when they are doing NFB, or the supervisor who 
> will configure the filter for the specific purpose.
> 
> I would like to suggest that we work toward a set of html pages which 
> define the various blocks and objects that make up the overall application, 
> with a master html that defines the app in its entirety. For now we need a 
> page that defines the 'objectives and features' that the app will include. 
> Effectively this 'objectives and features' page could be the initial 
> collection point for the various ideas that folk will come up with. Such a 
> set of pages becomes a site where the overall app is defined, but with 
> seperate pages for each Object. Obviously the application itself is the 
> central object.
> 
> I have some ideas that I am working on for graphical presentation of 
> complex object sets, so this could be useful.
> 
> I'm just thinking out loud here. Is this doable or not. ??

Hi,

I'm not trying to be rude here, nor am I trying to do any name-calling,
especially since I just got on this list, so I am not as familiar with
the discussion as you likely are.

However, if you are talking about creating some new piece of software of
which no parts have been written yet, spending enormous amounts of
energy on the front end to try to get a coordinated vision between
multiple players of what it will become is largely a waste. Especially
on the front end of development, it seems the way to go is for one
person to have a clear vision of what they are doing, spend some time
producing code, and THEN have others wrap their head around it and start
adding on. If things get big enough then bring on the automated
program-part tests.

Anything else is just spending way too much effort on "collaboration"
and way too little effort on coding ;-)

Seriously, judge projects based on what they produce, not on what they
plan to produce.

jeff

Hi Jeff, welcome to the discussion. You make some good points.

>I'm not trying to be rude here, nor am I trying to do any name-calling,
>especially since I just got on this list, so I am not as familiar with
>the discussion as you likely are.

I too try to avoid this. We are all volunteers and much great work has 
already been done. Credit to all.


>However, if you are talking about creating some new piece of software of
>which no parts have been written yet, spending enormous amounts of
>energy on the front end to try to get a coordinated vision between
>multiple players of what it will become is largely a waste.

I guess I must disagree with you on this, I think it is most important that 
we do this exercise in definition. How can planning ever be a 'waste of 
time'. from my experience things that have no overall plan or prior 
statement of vision tend to develop into an adhoc mishmash of whatever it 
is, and are very difficult for those that come along after to follow. I 
have done this so many times, not with software specifically but in other 
areas of life and of engineering. We need planning and we need 
communication and obviously we will need compromise. Isn't this the very 
nature of collaboration.

I do agree however that the multiplicity of ideas is a BIG problem and it 
is this problem that we need a creative solution to. What that might be is 
part of the plan imo.

>Especially
>on the front end of development, it seems the way to go is for one
>person to have a clear vision of what they are doing, spend some time
>producing code,

The purpose of such a plan is to clarify the vision for the person or 
persons involved. But it also provides a framework on which collaboration 
can evolve.

>and THEN have others wrap their head around it and start
>adding on.

I know what you mean, but I think it is a cart before the horse approach. 
This is the problem that I see needs avoiding. I wonder what others think?. 
I could be entirely in my own little idealist fantasy world on this.

>  If things get big enough then bring on the automated
>program-part tests.

The purpose of a well thought out and planned and documented design is to 
provide a cohesive framework that will provide structural integrity to the 
thing. Sure that sounds grandiose, but it is essential imo to help avoid 
the pitfalls. Maybe I am wrong.

Jeff..it is interesting that you should state this view, since it defines 
and frames problem, as I see it, quite nicely. Your view and mine are in 
almost total opposition and this is definitely a good thing.

Ian








>Anything else is just spending way too much effort on "collaboration"
>and way too little effort on coding ;-)
>
>Seriously, judge projects based on what they produce, not on what they
>plan to produce.
>
>jeff
>
>
>
>-------------------------------------------------------
>This SF.net email is sponsored by: SF.net Giveback Program.
>Does SourceForge.net help you be more productive?  Does it
>help you create better code?  SHARE THE LOVE, and help us help
>YOU!  Click Here: http://sourceforge.net/donate/
>_______________________________________________
>Openeeg-list mailing list
>Openeeg-list@...
>https://lists.sourceforge.net/lists/listinfo/openeeg-list
>Go to the above address to change your
>subscription options, e.g unsubscribe.

i wish all of you young fellows great health, good
cheer, lots of gusto, happy holidays and a productive
new year.

with out a doubt, the software will bloom. this
particular group continually tickles me, as able
newbies lend a hand.
 
ebb

__________________________________
Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard
http://antispam.yahoo.com/whatsnewfree

On Sun, 2003-12-14 at 04:02, Ian Vincent wrote:
> I guess I must disagree with you on this, I think it is most important that 
> we do this exercise in definition. How can planning ever be a 'waste of 
> time'. from my experience things that have no overall plan or prior 
> statement of vision tend to develop into an adhoc mishmash of whatever it 
> is, and are very difficult for those that come along after to follow. I 

I did not state that there should not be an overall plan. I stated that
trying to get a coordinated vision between _multiple_ players on the
front end was largely a waste of effort, then said that "for one person
to have a clear vision" was the way to go.

> have done this so many times, not with software specifically but in other 
> areas of life and of engineering. We need planning and we need 
> communication and obviously we will need compromise. Isn't this the very 
> nature of collaboration.

Once something has been written that others can build on, there becomes
a need for the others to first have a clear understanding of how the
existing thing works. This can be gotten in several not necessarily
distinct ways:

- examining the code
- documentation
- explanation from the author

Either way, this is the phase where a large increase in communication is
required. However, as long as 1. the original thing was built in a
properly modular manner, and 2. the other people can understand it
through one of the above means, then there is a sufficient condition for
others to be ABLE to collaborate at this point. (Which doesn't mean they
will necessarily get it right; but certainly without these two things
there is NO way for them to get it right.)

> I do agree however that the multiplicity of ideas is a BIG problem and it 
> is this problem that we need a creative solution to. What that might be is 
> part of the plan imo.
>
> The purpose of such a plan is to clarify the vision for the person or 
> persons involved. But it also provides a framework on which collaboration 
> can evolve.

I was doing some coding last night, and I drew a data flowchart on a
whiteboard to help me figure out how to write it. There is certainly
room for written plans for individuals to follow when doing initial
coding. However, if the plan is too vague, or has structural problems,
as it likely will be with multiple people trying to construct it without
any working code to back up the visualized organization, it isn't really
more useful than no plan at all.

Certainly once one person has written the code based off of a personal
plan they had, they can clean it up and publish it as a form of
documentation so that others can more quickly learn how the code works.

> I know what you mean, but I think it is a cart before the horse approach. 
> This is the problem that I see needs avoiding. I wonder what others think?. 
> I could be entirely in my own little idealist fantasy world on this.
> 
> The purpose of a well thought out and planned and documented design is to 
> provide a cohesive framework that will provide structural integrity to the 
> thing. Sure that sounds grandiose, but it is essential imo to help avoid 
> the pitfalls. Maybe I am wrong.

Structural integrity grows out of a clear vision that is appropriately
in touch with the reality of the programming language. However you wish
to achieve the initial clear vision is up to you; it is my suggestion
that overloaded front-end collaboration will not help you get to where
you want to be.

> Jeff..it is interesting that you should state this view, since it defines 
> and frames problem, as I see it, quite nicely. Your view and mine are in 
> almost total opposition and this is definitely a good thing.

Hehe :-)

To bring in some proper jargon to the discussion, this dichotomy is
elsewhere termed as that between "lawful" and "chaotic". I hear D&D uses
those attributes for characters, although I have never played it myself.
For the advanced students among you, I will refer you to chapter 17 of
Psybermagick by Peter J. Carroll.

Your idea of posting a list of features that you would like to see can
certainly be a good way to start off; someone else can then take that as
inspiration for the start of some code, and add things in as it gets
more mature.

jeff

I agree that there should be a list of features that people want to 
see.  Perhaps it can be on the openeeg.sf.net web pages.  I have 
noticed, though, that the admins and developers of the OpenEEG project 
have so far been silent on this discussion.  Perhaps something similar 
to a guestbook can be used so anybody can come along and post their 
ideas.  Then somebody else can compile and orgranize the ideas in html 
form.  I think both parts are necessary, because the guestbook will be 
very unorganized, but the person compiling and organizing will 
inadvertently put their own slant on things.

But the planning can only be taken so far.  For one thing, different 
people use different programming languages, so there won't be just one 
application, but several.  And the people actually doing the coding will 
all have their own ideas.  Only time will tell how many applications 
evolve to a useable form.  These different languages can share code to a 
large extent, though, and perhaps there could also be a page where the 
different projects in development can be listed.  The open source 
projects can share code, and anyone who wants to participate in the 
development process can see where to go.

Jeremy Wilkerson wrote:

> I agree that there should be a list of features that people want to 
> see. 


A thought from the peanut gallery: Since BioExplorer seems to be 
the software of choice for those with functioning equipment, might 
it not be a potential source of inspiration? A key feature or two 
as the initial target (the "poor man's" version), and a user 
interface that mimics or improves upon (always a source of 
controversy, i know) the current "standard".

Hi everybody,

First, I'd like to say how impressed I am that you hardware hackers have
managed to get this EEG system working at such a low cost!  Unbelievable!
I just went to a machine learning conference in Tuebingen, Germany a
couple months ago, and talked with a researcher doing some EEG experiments
to let totally paralyzed people "type" using brainwaves and flashing
letters (no muscles involved).  I was interested enough to ask him how
much the EEG setup costs minimum for the hardware and he said they couldn't
get the cost below $1200, though they did try to save where they could.
So I'm really amazed that you folks have worked the price down to about
$200, that's an incredible accomplishment!  I wonder if your system
is sensitive enough to pick up the so-called "P300" brainwave, which
my friend has been using for his research in brain-computer-interfacing.

Second, I wanted to offer some help with the software part of this
project.  I've had a lot of experience writing software in most of
the major languages; you can see some of my open source stuff on
SourceForge, or on my homepage at http://www.cwi.nl/~cilibrar
or maybe elsewhere on the net.  I haven't got a ModularEEG board
yet nor have I tried this BioExplorer that has been mentioned, but I
have done some signal processing and seen some EEG research software
so have some idea about what's supposed to happen.  My intuition says
that the correct way to start this project is in ANSI C, in particular,
use gcc with the -Wall (all warnings) option.  At this stage core
functionality can be written such as signal processing, data capture or
hardware driver modules, and a "viewer" interface (where the GUI or whatnot
attaches, etc).  Once we've got that core worked out, then I think it
makes sense to wrap those functions in "bindings" of our choosing as
necessary, such as Perl, C++, Ruby, Java, and probably some sort of socket
networking layer.  I think that if we start in any language other than
C this project will wind up being too much work to get done, as most
other languages have enough frills to distract you from the problem at
hand.  Also, there's a lot of great libraries we can use in C such as
CBLAS and GSL that will come in handy.  With good use of function pointers
the dynamic or polymorphic binding features of Java/C++ can be emulated
in plain ANSI C without all the extra conceptual overhead.  The simplicity
of ANSI C will translate to a cleaner, smaller, more consistent design if
it's the primary language in which the core is written, and will enable
good seperation of model, view and controller aspects of the program
later on for different interface skin options.

Best wishes and Happy Holidays brain surfers!!

Rudi


On Sat, Dec 13, 2003 at 08:33:15AM +1300, Ian Vincent wrote:
> I know it is a very childish thing to ask 'why', but I am going to ask

Attached is an .html document defining an object set that could be used in 
the application design. The active word is PRELIIMINARY.

It is a reflection of what I see happening in the real world of NFB, and my 
own personal experience, rather than the internal workings of any specific 
programming language.

Tomorrow I will do a pictorial of the set as it stands so that we have 
something visual to look at.

I hope the file gets through OK.

Ian

From: "Ian Vincent" <vincent@...>
...
> How an we improve this situation. What is the norm for collaborative
> software development. Are there tools out there for use in this area, or
> are these tools so complex that they become there own project.

SourceForge is the leading open source development tool, as far as I know.

> What I think is needed is a fresh start, a new approach, an over all plan,
> a collaborative software project.

I agree that we need a collaborative software project.  I don't think an all
over plan is necessary.  Developers don't need to be constrained to a
specific plan, one isn't required for open source work.  As developers add
their modifications, they are either integrated into the project, or can
split into side projects if they are truely incompatible.

> How do we do this guys. How can I help. How can we keep this flexible, and
> open, and evolving into the future. How do we guaruntee that the project
> will end up with a working software at the end of all of this.

I think that somebody needs to "step up to the plate" and release open
source, working software.  Once this happens tons of developers will jump on
board because it is far easier to modify working code than to start from
scratch.  Even average users of the software can jump in and make small
modifications to suit their purposes.

I'm trying to "step up to the plate" myself, and I twiddled around with
serial port code long enough to decide that a kernel-mode driver (for WinXP)
is the way to go.  I don't know much about writing drivers, so my progress
has been slow to nonexistant.

Because of that, I started looking at using LabView.  Labview is in many
ways the ideal environment for doing everything we need to do, it's also
fairly simple to use and has cross platform support.  The downside is that
labview costs big bucks.  It is possible to compile actual programs using
labview application builder, but that also costs big bucks.  Luckily my
school has a few labview licenses.

I have a semi-working program that works with my own firmware revision.  The
only problem it has now is that it occasionaly inserts a random number into
the test pattern.  It is related to the assembly or dissasembly of the 16
bit numbers, but I can't seem to track it down.

When i have it working, it will be a decent basis for any sort of labview
program you can concieve.  Labview has JTFA, several different oscilloscope
type views, filters, spectral analysis, etc.  You can string them together
however you want with drag and drop simplicity.

I would like to see an open source C program produced, and will eventually
do it myself, but I'm not holding my breath.


> What happened to the object library.?? and where is it defined. Can it be
> used or is it old and crusty.
>
> Ian

I don't think that anything ever came of it.  It was overreaching and not
very tightly tied to the ModEEG.

-Jake

I read the comments after my post went out, and I have to say I agree with
Jeffrey Bridge.  I think he hit the nail on the head.  When writing
applications coders almost always use the idea of "top down design - bottom
up coding", what I see is a plethora of top down design, but little bottom
up coding.  We're still on the floor so to speak.

Ian has released a top down design diagram which I think exemplifies the
problem (no offence Ian).  The top down design is already overcomplicated,
and adhering to it could slow down the development.  One basic problem is
that if a programmer is doing the bottom up coding, why would he adhere to
your top down design?  It could be accomplished it we had a team of
dedicated developers all working in the same language, who would be willing
to accept the athority of someone who doles out the pieces.  I don't think
this is going to happen.

How would athority/respect of this kind be established?  Simple, a person
who writes a working program becomes the authority and takes the lead over
any developers that wish to join.  Since we aren't at that point yet, I
would suggest that Joerg or Andreas would be the logical persons to be in
charge of the development.  They could probably pull this off, but I'm not
sure that anything would happen faster than waiting for somebody to write
the first program.

In order to get the first program out, I would suggest the simpleist of
designs.  A direct copy of ElecticGuru would be fine.  There will be plenty
of time to add fancy features later.  All the program really has to do is
aquire the data and display it as a waveform/FFT.  I would suggest that each
display does it's own filtering and processing, unless there is a compelling
reason to do it first. (i.e. all displays need the same processing.)

So my proposal for inital design is an order of magnitudes smaller than
Ian's.

1. Aquire data, perform processing and controll required by all display
modules.
    a.  Display as waveform
    b.  Display as FFT

Any requirements beyond this can wait until we have a working program that
will draw developers.

-Jake

P.S.  Ian don't let this discourage you, your input is valuable, you are
just overeager, as we all are.

On Sat, 2003-12-13 at 22:15, Jake wrote:
> I read the comments after my post went out, and I have to say I agree with
> Jeffrey Bridge.  I think he hit the nail on the head.  When writing
> applications coders almost always use the idea of "top down design - bottom
> up coding", what I see is a plethora of top down design, but little bottom
> up coding.  We're still on the floor so to speak.

oh my, i'm not quite sure how i failed to make the connection earlier:

the cathedral and the bazaar

:)

jeff

At 08:15 PM 12/13/2003 -0800, you wrote:
>I read the comments after my post went out, and I have to say I agree with
>Jeffrey Bridge.  I think he hit the nail on the head.  When writing
>applications coders almost always use the idea of "top down design - bottom
>up coding", what I see is a plethora of top down design, but little bottom
>up coding.  We're still on the floor so to speak.

Jake..I did say it was from a user perspective which equates to a top down 
perspective exactly as you describe. I make no apologies for that since it 
exactly where I am. A user. However I do believe that users are the 
potential beneficiaries of this project and in particular those of us who 
can benefit from NFB.

The stuff about authority is interesting tho..and frankly I am suprised. I 
don't claim any authority at all and simply responded to a request for 
ideas, I thought that was the best way to express those ideas. I guess most 
folk only want to work on their own designs, and therefore be their own 
'authority' as you put it. But where is the collaboration in that.

It will be interesting to see what others think, though I expect most of 
the software guys will be similar to you. If nothing else i now have a 
perspective on the original question Why??

Oh well, it was fun, and it did help to clarify things for me, even if it 
goes nowhere, which is highly probable. I guess it was a bit gandiose, 
cathedral like, as Jeff suggested, but then again, that's what dreams are for.

Ian

From: "Ian Vincent" <vincent@...>
> The stuff about authority is interesting tho..and frankly I am suprised. I
> don't claim any authority at all and simply responded to a request for
> ideas, I thought that was the best way to express those ideas.

I didn't mean to imply that you any claimed authority, simply that some
authority/direction/manegment would be required to develop software in the
manner you suggest.  Jeff came up with the excellent cathedral - bazzar
analogy.  What you have done is design a cathedral.  This works only if you
are the Pope.  It's a fine way to design software if you are a company and
have a clear authority structure, but what we have is a bazzar.  If you
could convince the bazzar to suddenly build a cathedral, it would be truely
wonderous, but unrealistic.

> I guess most
> folk only want to work on their own designs, and therefore be their own
> 'authority' as you put it. But where is the collaboration in that.

You always have to estimate weither is would be faster to learn somebody
elses code and improve upon it, or to start fresh.  Since there really isn't
any code yet, it would be hard to get people on board with just a design.

> Oh well, it was fun, and it did help to clarify things for me, even if it
> goes nowhere, which is highly probable. I guess it was a bit gandiose,
> cathedral like, as Jeff suggested, but then again, that's what dreams are
for.

I hope I haven't discouraged you.  It's posts like yours that keep
developers going by providing new ideas, showing support, and consolidating
design goals.  We are all chomping at the bit for a killer app, but these
things take time.  I plan to release my test firmware in the next few days,
with a lot more source code comments.  I'm hoping that others can use it for
validating the data acquisition portions of their code.  Meanwhile I have
been working on my LabView app, and hope to have a basic program within the
next few months.

-Jake

>
>I didn't mean to imply that you any claimed authority, simply that some
>authority/direction/manegment would be required to develop software in the
>manner you suggest.

I see it as a bunch of rooms, rather than a cathedral, but "cathedral" 
would be a great name for such an app, anyway.

The reason that I say that is because with alcoholism, the standard age old 
treatment is to get 'god' , AA style, and since NFB is also very 
effectitive, this becomes the new 'cathedral' . NFB and Addiction is my 
specialist area and it is this community who I am trying to help by 
bringing NFB to the masses. Affordable and practical software is now the 
key to this, now that we have ModEEG available.

This is my motivation for designing such a monstrosity in the first place, 
ie so that we have a practical tool for remotely supervised NFB sessions, 
that doesn't cost the earth. However if it can't be done OpenSource then 
maybe I need to look somewhere other than the bazaar.

I have little concept of what effort is involved with  building such an 
object set, but I knew it wouldn't be an easy task. However somehow the 
idea of defining a logical object set seemed to me to be natural thing to 
do since it defines the various rooms and potentially different folk could 
work on each room without having to build the whole damn cathedral themselves.

But today I see a half a dozen software guys responding to this thread, and 
each has a different language specialty and each think that their approach 
is the way to go, so I guess we will always be stuck in the bazzar. What we 
need is a Walmart, not a bazzar.<g>


>Jeff came up with the excellent cathedral - bazzar
>analogy.  What you have done is design a cathedral.  This works only if you
>are the Pope.  It's a fine way to design software if you are a company and
>have a clear authority structure, but what we have is a bazzar.  If you
>could convince the bazzar to suddenly build a cathedral, it would be truely
>wonderous, but unrealistic.

I understand this now, though it doesn't solve my problem, but at least it 
has clarified what my problem is, and how big it actually is,. Tooo big.

>You always have to estimate weither is would be faster to learn somebody
>elses code and improve upon it, or to start fresh.  Since there really isn't
>any code yet, it would be hard to get people on board with just a design.

Maybe this has gotten people thinking a bit about this software issue, it 
surely has me. I don't think I ever saw so many posts in one day before. 
That's an achievement in itself.


>I hope I haven't discouraged you.

You haven't, its more a matter of refocusing on how to achieve the impossible.

>It's posts like yours that keep
>developers going by providing new ideas, showing support, and consolidating
>design goals.  We are all chomping at the bit for a killer app, but these
>things take time.  I plan to release my test firmware in the next few days,
>with a lot more source code comments.  I'm hoping that others can use it for
>validating the data acquisition portions of their code.  Meanwhile I have
>been working on my LabView app, and hope to have a basic program within the
>next few months.

Good luck with the foundations, How many do you reckon a cathedral will 
need??;-)

Ian

Hi Rudi,

I disagree with you on several points about choice of language, but I'm 
not going to explain my reasons because it really doesn't matter.  We 
don't need a debate about programming languages.  I am going to work on 
a Java application because I feel it is the best choice (though I'm sure 
if I had more experience in another language, I would mentally weight 
the factors differently and would prefer the other language).

C is a good non-object language, and I offer my encouragement to anyone 
who writes software for ModEEG in C, C++, Pascal, Logo, or any other 
language.  But not C# because it's made my Microsoft...just kidding.

Jeremy


Rudi Cilibrasi wrote:

>Hi everybody,
>
>First, I'd like to say how impressed I am that you hardware hackers have
>managed to get this EEG system working at such a low cost!  Unbelievable!
>I just went to a machine learning conference in Tuebingen, Germany a
>couple months ago, and talked with a researcher doing some EEG experiments
>to let totally paralyzed people "type" using brainwaves and flashing
>letters (no muscles involved).  I was interested enough to ask him how
>much the EEG setup costs minimum for the hardware and he said they couldn't
>get the cost below $1200, though they did try to save where they could.
>So I'm really amazed that you folks have worked the price down to about
>$200, that's an incredible accomplishment!  I wonder if your system
>is sensitive enough to pick up the so-called "P300" brainwave, which
>my friend has been using for his research in brain-computer-interfacing.
>
>Second, I wanted to offer some help with the software part of this
>project.  I've had a lot of experience writing software in most of
>the major languages; you can see some of my open source stuff on
>SourceForge, or on my homepage at http://www.cwi.nl/~cilibrar
>or maybe elsewhere on the net.  I haven't got a ModularEEG board
>yet nor have I tried this BioExplorer that has been mentioned, but I
>have done some signal processing and seen some EEG research software
>so have some idea about what's supposed to happen.  My intuition says
>that the correct way to start this project is in ANSI C, in particular,
>use gcc with the -Wall (all warnings) option.  At this stage core
>functionality can be written such as signal processing, data capture or
>hardware driver modules, and a "viewer" interface (where the GUI or whatnot
>attaches, etc).  Once we've got that core worked out, then I think it
>makes sense to wrap those functions in "bindings" of our choosing as
>necessary, such as Perl, C++, Ruby, Java, and probably some sort of socket
>networking layer.  I think that if we start in any language other than
>C this project will wind up being too much work to get done, as most
>other languages have enough frills to distract you from the problem at
>hand.  Also, there's a lot of great libraries we can use in C such as
>CBLAS and GSL that will come in handy.  With good use of function pointers
>the dynamic or polymorphic binding features of Java/C++ can be emulated
>in plain ANSI C without all the extra conceptual overhead.  The simplicity
>of ANSI C will translate to a cleaner, smaller, more consistent design if
>it's the primary language in which the core is written, and will enable
>good seperation of model, view and controller aspects of the program
>later on for different interface skin options.
>
>Best wishes and Happy Holidays brain surfers!!
>
>Rudi
>
>
>On Sat, Dec 13, 2003 at 08:33:15AM +1300, Ian Vincent wrote:
>  
>
>>I know it is a very childish thing to ask 'why', but I am going to ask 
>>    
>>
>
>
>-------------------------------------------------------
>This SF.net email is sponsored by: SF.net Giveback Program.
>Does SourceForge.net help you be more productive?  Does it
>help you create better code?  SHARE THE LOVE, and help us help
>YOU!  Click Here: http://sourceforge.net/donate/
>_______________________________________________
>Openeeg-list mailing list
>Openeeg-list@...
>https://lists.sourceforge.net/lists/listinfo/openeeg-list
>Go to the above address to change your
>subscription options, e.g unsubscribe.
>
>  
>

I appreciate Ian's outline because it explains aspects of neurofeedback 
that I wasn't aware of, such as the explanations about sessions, 
segments, and supervisors.

It's important to start out simple, but it's also important to know 
where you're going.  That way you can design the code so that it's 
easier to build upon later without having to redo everything (and 
without other developers needing to understand every detail of the 
original code).


Jake wrote:

>I read the comments after my post went out, and I have to say I agree with
>Jeffrey Bridge.  I think he hit the nail on the head.  When writing
>applications coders almost always use the idea of "top down design - bottom
>up coding", what I see is a plethora of top down design, but little bottom
>up coding.  We're still on the floor so to speak.
>
>Ian has released a top down design diagram which I think exemplifies the
>problem (no offence Ian).  The top down design is already overcomplicated,
>and adhering to it could slow down the development.  One basic problem is
>that if a programmer is doing the bottom up coding, why would he adhere to
>your top down design?  It could be accomplished it we had a team of
>dedicated developers all working in the same language, who would be willing
>to accept the athority of someone who doles out the pieces.  I don't think
>this is going to happen.
>
>How would athority/respect of this kind be established?  Simple, a person
>who writes a working program becomes the authority and takes the lead over
>any developers that wish to join.  Since we aren't at that point yet, I
>would suggest that Joerg or Andreas would be the logical persons to be in
>charge of the development.  They could probably pull this off, but I'm not
>sure that anything would happen faster than waiting for somebody to write
>the first program.
>
>In order to get the first program out, I would suggest the simpleist of
>designs.  A direct copy of ElecticGuru would be fine.  There will be plenty
>of time to add fancy features later.  All the program really has to do is
>aquire the data and display it as a waveform/FFT.  I would suggest that each
>display does it's own filtering and processing, unless there is a compelling
>reason to do it first. (i.e. all displays need the same processing.)
>
>So my proposal for inital design is an order of magnitudes smaller than
>Ian's.
>
>1. Aquire data, perform processing and controll required by all display
>modules.
>    a.  Display as waveform
>    b.  Display as FFT
>
>Any requirements beyond this can wait until we have a working program that
>will draw developers.
>
>-Jake
>
>P.S.  Ian don't let this discourage you, your input is valuable, you are
>just overeager, as we all are.
>
>
>
>
>
>
>
>
>
>
>
>
>-------------------------------------------------------
>This SF.net email is sponsored by: SF.net Giveback Program.
>Does SourceForge.net help you be more productive?  Does it
>help you create better code?  SHARE THE LOVE, and help us help
>YOU!  Click Here: http://sourceforge.net/donate/
>_______________________________________________
>Openeeg-list mailing list
>Openeeg-list@...
>https://lists.sourceforge.net/lists/listinfo/openeeg-list
>Go to the above address to change your
>subscription options, e.g unsubscribe.
>
>  
>

At 06:14 AM 12/14/2003 -0700, you wrote:
>I appreciate Ian's outline because it explains aspects of neurofeedback 
>that I wasn't aware of, such as the explanations about sessions, segments, 
>and supervisors.

Jeremy

Interesting that you say that, and I hadn't seen it before but the extra 
complexity around the user/trainee/supervisor objects and 
session/segment/layout objects all stems from the needs of self training 
and home training. It is one thing to sit in a therapists office and have 
the therapist twiddle the machine, and quite another to do it to yourself.

In effect the sophistication of the software compensates for the lack of 
therapist. So in effect home or self training, which is our target user, 
requires more complex software than a clinical situation, since it also 
serves some of the roles that a one to one therapist would normally perform.

Now that is bazaar.

Ian



>It's important to start out simple, but it's also important to know where 
>you're going.  That way you can design the code so that it's easier to 
>build upon later without having to redo everything (and without other 
>developers needing to understand every detail of the original code).

Hi !

> A thought from the peanut gallery: Since BioExplorer seems to be
> the software of choice for those with functioning equipment, might
> it not be a potential source of inspiration? A key feature or two
> as the initial target (the "poor man's" version), and a user
> interface that mimics or improves upon (always a source of
> controversy, i know) the current "standard".

First of all, if I remember right we discussed such BioExplorer or LabView 
like ideas long before we knew about BioExplorer.
I still think this would be the way to go and there hasn't been much dissent 
about it in the group as well. 

Write a library with objects that can be configured through text files and 
later on write a GUI to make the configuration more convenient, that would be 
the way to go. 

- We could use the free SwitcherCAD (the PSPICE the hardware people on this 
group use) as a GUI to make the configuration files. First of all, it has a 
really good schematic editor (one of the best I ever used).
Second it outputs easy to interpret netlist files. We could  make a set of 
symbols and so on for our purpose (like the IC analogy Ian was talking 
about), one for each object. 

- The most important work now would then be to design a scheme of 
communication between different objects and interfaces between the objects.

Then we need a couple of simple objects to start with and code to read the 
configuration file and setup the other objects. So after a planing stage of 
the communication interface we could start with a simple, minimal but working 
example setup (modEEG driver, maybe filter object, display time series 
object). 

If we document this right, after this has been done from people with some good 
software architecture knowledge, the rest of us could start to write own data 
processing objects.

Regarding reenwenting the wheel: there are some other open source projects 
with similar demands, maybe we could take some of their code ?

- The SDL library seems to be very good for platform independance and speed. I 
think we should stick to it. Other choices of platform independant 
gui/graphic libraries could be wxWindows, FOX, Java or Qt. But they all have 
their advantages and disadvantages, and I think regarding speed and number of
platforms SDL is the best.



 Moritz

Ian Vincent wrote:
> At 06:14 AM 12/14/2003 -0700, you wrote:
> 
>> I appreciate Ian's outline because it explains aspects of 
>> neurofeedback that I wasn't aware of, such as the explanations about 
>> sessions, segments, and supervisors.
> 
> 
> Jeremy
> 
> Interesting that you say that, and I hadn't seen it before but the extra 
> complexity around the user/trainee/supervisor objects and 
> session/segment/layout objects all stems from the needs of self training 
> and home training. It is one thing to sit in a therapists office and 
> have the therapist twiddle the machine, and quite another to do it to 
> yourself.
> 
> In effect the sophistication of the software compensates for the lack of 
> therapist. So in effect home or self training, which is our target user, 
> requires more complex software than a clinical situation, since it also 
> serves some of the roles that a one to one therapist would normally 
> perform.
> 
> Now that is bazaar.
> 
> Ian
> 
>> It's important to start out simple, but it's also important to know 
>> where you're going.  That way you can design the code so that it's 
>> easier to build upon later without having to redo everything (and 
>> without other developers needing to understand every detail of the 
>> original code).
> 

Ian has certainly set out an ambitious goal. I confess to knowing 
nothing of modern computer languages but it appears there might be 
room for multiple skill levels: 1) the hard core "nuts and bolts" 
crowd dealing with hardware communication, filter design etc. 2) 
people who could handle higher level languages to do tasks such as 
  session setup, session management, etc. 3) Support from the 
peanut gallery might also come in the way of research ... scouring 
the net for canned routines or technical info to accomplish a task.

I'm wondering, within the framework of this suggested goal, is 
there a possible minimal starting point for people to begin using 
the software or is it something that might require say 1000 hours 
to get to any place useful? (I realize this is a very vague 
question, depending on what the minimal starting point might be 
and the current knowledge and skills of anyone attempting to get 
there.)

Finally, I'm curious what might motivate potential software 
contributors to take on the task.

From: "Moritz von Buttlar" <info@...>
> - The most important work now would then be to design a scheme of
> communication between different objects and interfaces between the
objects.

I agree.  I know you have done some good work with the firmware.  What is
the status of the bidirectional protocol?

I think one thing that might be slowing software development is the feeling
that the firmware isn't finished yet.  It would be optimal to get all the
features of the modeeg working and standardize on a protocol before writing
an API.  I came up with a short list of features that I think should be
included in the firmware...

1. Ability for unit to identify itself.  i.e. it prints out "ModEEG v1.0"
upon request.
2. Ability to start and stop sampling/transmission upon request.
3. Ability to identify current protocol used. (after the next version, the
firmware should support switching between any further versions)
4. Ability to read the state of switches upon request.
5. Ability to set switches via software when switches are used in output
mode.
6. Ability to set PWM output via software.
7. Ability to transmit a test pattern for verification of serial link and
acquisition software.
8. Ability to set sampling rate/comm speed via software.

I hope everyone will comment on this feature set...

-Jake

> - The SDL library seems to be very good for platform independance and speed. I 
> think we should stick to it. Other choices of platform independant 
> gui/graphic libraries could be wxWindows, FOX, Java or Qt. But they all have 
> their advantages and disadvantages, and I think regarding speed and number of
> platforms SDL is the best.
> 

http://www.libsdl.org/intro/toc.html

Ian

You are right - all of the problems are included in software development.
While hardware is too critical - that we have to have some consensus,
otherwise it would not work, with software is the situation much diferent.
There are far too many variables to make one piece that will suit everyone,
this is impossible - even in OpenEEG project I reckon.
Someone needs just simple viewer, another one wants to script his own
sessions, or modules (preferably in his favourite programming language),
another wants to have features you cannot find in any other tool.
Just take the nubmer of programming languages, operating systems,
features requested, and the piece should be maybe easy to install and
understand. This makes it so difficult.
Anyway, this is only the first phase, eventually there will be two or three
branches running, but now the field is quite empty and we have to explore
it by so many approaches we can.

I do not say that hardware design is easy, but to specify hardware features
and goals is much easier than the software goals. There were time when
software was built to suit some hardware, but in present the situation
is reversed. The NFB software is even more difficult because human-kind
knowledge is still limited in this developing area.

As the first thing we should agree on the features - I think this was never
discussed and closed here. I mean FFT, digital filters, scripting etc.
This is called requirements analysis.
Then some kind of architecture and workflow (software design). If we use
OOP, than UML diagrams would be helpful (class, sequence, state, activity,
...).
When we specify this we could move to implementation analysis and
prototyping (this is platform dependent). Then to implementation. We need to
include testing and reviewing when necessary.
This is a rough development cycle, however I am not an software engineer.

cheers
Nelo

----- Original Message -----
From: "Ian Vincent" <vincent@...>
To: <openeeg-list@...>
Sent: Friday, December 12, 2003 8:33 PM
Subject: [Openeeg-list] Why??


> Hi there and Why? there
>
> I know it is a very childish thing to ask 'why', but I am going to ask
> anyway because I simply don't understand. I hope no one takes this as a
> personal criticism, they are only my comments, and thoughts around
software.
>
> Why is it that this project has had numerous attempts at software projects
> that seem to get started and then go so far, then stop. Is it a feature of
> software authoring, that the author gets bored or distracted and moves
onto
> other projects.
>
> Or is it that the Author under estimates the time it takes, and eventually
> other priorities crop up.
>
> Or is it that its so damn complex that the author gets lost.
>
> Or is it that the Author loses interest.
>
> Or is it something else all together.
>
> Or is it that Software is endless in itself.
>
> Being a hardware guy, I used to envy software guys because of their
ability
> to work together collaboratively over the internet, sharing code and
ideas,
> etc. I thought this was something that Hardware guys couldn't actually do.
> But the evidence from this OpenEEG project is just the opposite to what I
> used to think. The Hardware seems to evolve spontaneously, with intense
> levels of interest, and the posting back and forward of spice models and
> text and PCB designs, and out of the end pops a proffesional PCB that does
> the job.
>
> So what's happening with the software. Is it more difficult to work
> collaboratively. Are there so many variables and combinations and
> permutations that it gets sidetracked or what. I don't recall any details
> of the inner workings of the various project softwares posted here. No
> plans or sketches or models or flow diagrams or such. So how would there
> ever be collaboration if there is nothing of this nature. I have seen some
> code that I don't understand because I don't do code, so cant use. I also
> have BioExplorer that I can't see the code but can use. As an Opensource
> project we need installable code that actually does something, yet has
> opensource.  It seems to be about how to define what the 'does something'
> actually is, before the coding starts, perhaps.
>
> How an we improve this situation. What is the norm for collaborative
> software development. Are there tools out there for use in this area, or
> are these tools so complex that they become there own project.
>
> What I think is needed is a fresh start, a new approach, an over all plan,
> a collaborative software project. Now that we have a reliable and stable
> hardware platform, ie modEEG,  this is possible. It opens the gate to
> software developers and we might now see some sustained progress. I am
sure
> in the past the sheer time involved in getting a EEG device functioning
> provided enough alligators to ever prevent the swamp being cleared.
>
> How do we do this guys. How can I help. How can we keep this flexible, and
> open, and evolving into the future. How do we guaruntee that the project
> will end up with a working software at the end of all of this.
>
> What happened to the object library.?? and where is it defined. Can it be
> used or is it old and crusty.
>
> Ian
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: SF.net Giveback Program.
> Does SourceForge.net help you be more productive?  Does it
> help you create better code?  SHARE THE LOVE, and help us help
> YOU!  Click Here: http://sourceforge.net/donate/
> _______________________________________________
> Openeeg-list mailing list
> Openeeg-list@...
> https://lists.sourceforge.net/lists/listinfo/openeeg-list
> Go to the above address to change your
> subscription options, e.g unsubscribe.

Hi again everybody,

I've been exchanging emails with Jake and Moritz, and would like to get
started on some of the software development tasks at hand.  I have
contacted Olimex about buying a ModularEEG, but unfortunately there are
two problems that prevent me from ordering:

1) It doesn't support the Atmega8 processor, which Jake has told me is
the more up-to-date.  I don't want to develop software for an obsolete
chip.

2) It doesn't include a programming cable, and the company can't make one.

Unfortunately, I'm terrible with a soldering iron (I use wire-wrap and
only build digital) and so this is a hurdle.  Can somebody give me some
suggestion about how I might get a working platform here with programming
capability on an Atmega 8?  I think the electrodes can be put off until 
the software is a little more developed.

I'm enthusiastic to get started as I really enjoyed writing firmware
the last time I did it in school and would love to help with this exciting
project.  I've reviewed the basic and bidirectional firmware code that
we already have and have reported the one potential bug I found to
Moritz, but now I'm really stuck without a working platform to play
with.

Thanks for any pointers,

Rudi

On Sat, Dec 13, 2003 at 08:33:15AM +1300, Ian Vincent wrote:
> Hi there and Why? there
> 
> I know it is a very childish thing to ask 'why', but I am going to ask 
> anyway because I simply don't understand. I hope no one takes this as a 
> personal criticism, they are only my comments, and thoughts around software.
> 
> Why is it that this project has had numerous attempts at software projects 
> that seem to get started and then go so far, then stop. Is it a feature of 
> software authoring, that the author gets bored or distracted and moves onto 
> other projects.
> 
> Or is it that the Author under estimates the time it takes, and eventually 
> other priorities crop up.
> 
> Or is it that its so damn complex that the author gets lost.
> 
> Or is it that the Author loses interest.
> 
> Or is it something else all together.
> 
> Or is it that Software is endless in itself.
> 
> Being a hardware guy, I used to envy software guys because of their ability 
> to work together collaboratively over the internet, sharing code and ideas, 
> etc. I thought this was something that Hardware guys couldn't actually do. 
> But the evidence from this OpenEEG project is just the opposite to what I 
> used to think. The Hardware seems to evolve spontaneously, with intense 
> levels of interest, and the posting back and forward of spice models and 
> text and PCB designs, and out of the end pops a proffesional PCB that does 
> the job.
> 
> So what's happening with the software. Is it more difficult to work 
> collaboratively. Are there so many variables and combinations and 
> permutations that it gets sidetracked or what. I don't recall any details 
> of the inner workings of the various project softwares posted here. No 
> plans or sketches or models or flow diagrams or such. So how would there 
> ever be collaboration if there is nothing of this nature. I have seen some 
> code that I don't understand because I don't do code, so cant use. I also 
> have BioExplorer that I can't see the code but can use. As an Opensource 
> project we need installable code that actually does something, yet has 
> opensource.  It seems to be about how to define what the 'does something' 
> actually is, before the coding starts, perhaps.
> 
> How an we improve this situation. What is the norm for collaborative 
> software development. Are there tools out there for use in this area, or 
> are these tools so complex that they become there own project.
> 
> What I think is needed is a fresh start, a new approach, an over all plan, 
> a collaborative software project. Now that we have a reliable and stable 
> hardware platform, ie modEEG,  this is possible. It opens the gate to 
> software developers and we might now see some sustained progress. I am sure 
> in the past the sheer time involved in getting a EEG device functioning 
> provided enough alligators to ever prevent the swamp being cleared.
> 
> How do we do this guys. How can I help. How can we keep this flexible, and 
> open, and evolving into the future. How do we guaruntee that the project 
> will end up with a working software at the end of all of this.
> 
> What happened to the object library.?? and where is it defined. Can it be 
> used or is it old and crusty.
> 
> Ian
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: SF.net Giveback Program.
> Does SourceForge.net help you be more productive?  Does it
> help you create better code?  SHARE THE LOVE, and help us help
> YOU!  Click Here: http://sourceforge.net/donate/
> _______________________________________________
> Openeeg-list mailing list
> Openeeg-list@...
> https://lists.sourceforge.net/lists/listinfo/openeeg-list
> Go to the above address to change your
> subscription options, e.g unsubscribe.

Ian Vincent wrote:
> Each block could be worked on by seperate people perhaps, and it is=20
> probable that some of the blocks already exist, in core form at least. =
Like=20
> Jim Peters work with filters obviously form the core for the filters th=
at=20
> we need, but may need packaging into an 'Filter' object of some sort, y=
et=20
> to be defined. This is a good example since it demonstrates my point. W=
hat=20
> inputs would such a 'Filter' object require and what outputs would it=20
> provide. Obviously such a 'Filter' object needs inputs of frequency ran=
ge=20
> and a data source and has output of filtered data and power/amplitude, =
but=20
> there could be others. We need to look at what services the user would=20
> require of such an object, and work from there.

Yes, the fidlib code is already object-oriented, although in a
C-language object orientation style [*].  It would be easy to put into
a wrapper class for use in a higher level language.

  http://uazu.net/fiview/

Jim

[* people forget that you can write object-oriented code in a non
object-oriented language]

--=20
 Jim Peters                  (_)/=3D\~/_(_)                 jim@...
                          (_)  /=3D\  ~/_  (_)
 Uaz=FA                  (_)    /=3D\    ~/_    (_)                http:/=
/
 Brighton, UK       (_) ____ /=3D\ ____ ~/_ ____ (_)            uazu.net

 Design/view/compare digital filters with Fiview:   http://uazu.net/FI

This looks really very good Ian. I think it is always good for software =
development that someone (user/client) keeps distance from what is going =
on in programming, so that we do not sacrifice usability to easiness of =
development. To have clear requirements is actually a big win and saves =
a lot of work (very often whole project).

I think this is going to be a long long way and a lot of communication, =
so I would suggest to organize the development little bit - into =
requirements, feasibility study, GUI, system architecture etc. It will =
be hard to discuss per email, so maybe wiki would be useful at this =
point.

Actually I have some ideas regarding architecture. Recently I have been =
working on socket server (in C#, sorry Jeremy :) but the VS IDE is =
simply great) as the core, responsible for communication with the device =
and signal preprocessing (FFT, digital filters). Second part is client =
(I am using Flash client because is so easy to script, similar language =
to Java/Javascript but even simpler) - this acts as view. Sessions are =
simply scripted in Flash (which offers more than powerful language for =
session scripting) and you hardly find an easier way how to do graphic =
interface and show feedback. Of course the client can be done in any =
language supporting socket communication and some graphics, but I have =
chosen Flash because it is so easy to script and use graphics.
What is more, you can connect several clients to such a server - also =
via Internet (as observers, or if you want to make some multi-player =
game, what is one of mine long-term goals). But several client modules =
means that you can create your own Light&Sound or Audio-biofeedback =
connector for virtually any device. Client and server communicates via =
XML packets. You can for example write your own client to suit your =
specific requirements in your favourite language and if you use the =
server you save maybe 60% of work.

To sum up, I decided for client-server architecture to break down the =
complexity of the system (which as you can see is an important issue) =
and to achieve very flexible, platform independent, internet enabled and =
modular solution. If you are interested I can send you preview of the =
piece, but it is in early prototyping stage, without any documentation.

Nelo
  ----- Original Message -----=20
  From: Ian Vincent=20
  To: openeeg-list@...
  Sent: Sunday, December 14, 2003 4:40 AM
  Subject: Re: [Openeeg-list] Why??


  Attached is an .html document defining an object set that could be =
used in=20
  the application design. The active word is PRELIIMINARY.

  It is a reflection of what I see happening in the real world of NFB, =
and my=20
  own personal experience, rather than the internal workings of any =
specific=20
  programming language.

  Tomorrow I will do a pictorial of the set as it stands so that we have =

  something visual to look at.

  I hope the file gets through OK.

  Ian

<html>
<body>
At 04:31 PM 12/15/2003 +0100, you wrote:<br>
<blockquote type=cite class=cite cite><font face="arial" size=2>This
looks really very good Ian. I think it is always good for software
development that someone (user/client) keeps distance from what is going
on in programming, so that we do not sacrifice usability to easiness of
development. To have clear requirements is actually a big win and saves a
lot of work (very often whole project).</font></blockquote><br>
Goal posts are important, even if someone keeps shifting them
;-)<br><br>
<blockquote type=cite class=cite cite>&nbsp;<br>
<font face="arial" size=2>I think this is going to be a long long way and
a lot of communication, so I would suggest to organize the development
little bit - into requirements, feasibility study, GUI, system
architecture etc. It will be hard to discuss per email, so maybe wiki
would be useful at this point.</font></blockquote><br>
Yes, how to keep such a project on track and so that everyone knows what
is going on, but also design documentation.&nbsp; <br><br>
<blockquote type=cite class=cite cite>&nbsp;<br>
<font face="arial" size=2>Actually I have some ideas regarding
architecture. Recently I have been working on socket server (in C#, sorry
Jeremy :) but the VS IDE is simply great) as the core, responsible for
communication with the device and signal preprocessing (FFT, digital
filters). Second part is client (I am using Flash client because is so
easy to script, similar language to Java/Javascript but even simpler) -
this acts as view. Sessions are simply scripted in Flash (which offers
more than powerful language for session scripting) and you hardly find an
easier way how to do graphic interface and show feedback. Of course the
client can be done in any language supporting socket communication and
some graphics, but I have chosen Flash because it is so easy to script
and use graphics.</font><br>
<font face="arial" size=2>What is more, you can connect several clients
to such a server - also via Internet (as observers, or if you want to
make some multi-player game, what is one of mine long-term goals). But
several client modules means that you can create your own Light&amp;Sound
or Audio-biofeedback connector for virtually any device. Client and
server communicates via XML packets. You can for example write your own
client to suit your specific requirements in your favourite language and
if you use the server you save maybe 60% of work.</font><br>
&nbsp;<br>
<font face="arial" size=2>To sum up, I decided for client-server
architecture to break down the complexity of the system (which as you can
see is an important issue) and to achieve very flexible, platform
independent, internet enabled and modular solution. If you are interested
I can send you preview of the piece, but it is in early prototyping
stage, without any documentation.</font></blockquote><br>
I'm interested..fire away<br><br>
Nelo..where would the server reside, would it be on the training machine,
or someplace else. The need for psuedo-real time response would require
it to be Trainee machine presumably. <br><br>
&nbsp;What sort of tools are available for generating flash. I only have
CorelDraw/Rave which exports to flash and would like to try something
else to widen my understanding. What do you recommend. ?? It has to be
free of course.<br><br>
Ian<br><br>
<br><br>
<br><br>
<br><br>
<br><br>
<br>
<blockquote type=cite class=cite cite>&nbsp;<br>
<font face="arial" size=2>Nelo</font><br>

<dl>
<dd>----- Original Message ----- <br>

<dd>From:</b> <a href="mailto:vincent@... Vincent</a> <br>

<dd>To:</b>
<a href="mailto:openeeg-list@...> <br>

<dd>Sent:</b> Sunday, December 14, 2003 4:40 AM<br>

<dd>Subject:</b> Re: [Openeeg-list] Why??<br><br>

<dd>Attached is an .html document defining an object set that could be used in <br>

<dd>the application design. The active word is PRELIIMINARY.<br><br>

<dd>It is a reflection of what I see happening in the real world of NFB, and my <br>

<dd>own personal experience, rather than the internal workings of any specific <br>

<dd>programming language.<br><br>

<dd>Tomorrow I will do a pictorial of the set as it stands so that we have <br>

<dd>something visual to look at.<br><br>

<dd>I hope the file gets through OK.<br><br>

<dd>Ian<br>

</dl></blockquote></body>
</html>

hi
 nello's approach is superb. its broadly interactive
enough to form an umbrella that allows independent
expansion of EEG o-op usage beyond current established
expert conceptual theory. anyone can afford to become
an unaffiliated student.

this relatively inexpensive research tool can become a
universally available means to investigate the king of
all physiological study.

hooray

tia
ebb

__________________________________
Do you Yahoo!?
New Yahoo! Photos - easier uploading and sharing.
http://photos.yahoo.com/

>>To sum up, I decided for client-server architecture to break down the
complexity of the system (which as you can see is an important issue) and to
achieve very flexible, platform independent, internet enabled and modular
solution. If you are interested I can send you preview of the piece, but it
is in early prototyping stage, without any documentation.

> I'm interested..fire away

>Nelo..where would the server reside, would it be on the training machine,
or someplace else. The need for psuedo-real time response would require it
to be Trainee machine presumably.

The server will need to sit on the same machine as the device, it needs to
connect to COM port and communicate with it.
Currently in C#, but it will be little problem to rewrite it to Java.
Does not need kernel mode driver because it uses kernel functions directly
(in unsafe mode).
There is an open-source C# tool for Linux as well, called MONO, but serial
port communication needs to be handled differently.

> What sort of tools are available for generating flash. I only have
CorelDraw/Rave which exports to flash and would like to try something else
to widen my understanding. What do you recommend. ?? It has to be free of
course.

The standard is open - there is a movement http://www.openswf.org/. It can
be viewed under Linux, Win and Mac. However the best tool is IDE from
Macromedia (not free).
But it will be a prototype of a thin client, so it would be easy to write it
in any other language. I chosen Flash because it is easy to work with and
powerful (graphics and socket communication), for this type of client
several times more productive than Java (no ofence) or C#. Just to proove
the concept of suitability of the client-server architecture for this type
of domain.

Nelo

Jake wrote:
> I think that somebody needs to "step up to the plate" and release
> open source, working software.  Once this happens tons of developers
> will jump on board because it is far easier to modify working code
> than to start from scratch.  Even average users of the software can
> jump in and make small modifications to suit their purposes.

With respect, there is already some working open-source software in
the form of EEGMIR and BWView -- and tons of developers have not
jumped on board as a result.

  http://uazu.net/bwview/
  http://uazu.net/eegmir/

Maybe we simply don't have enough developers with working modEEGs and
an itch that they need to scratch to get the ball rolling quite yet.
(Or maybe they all have different itches.)

However, someday there will be enough developers, and someone will
come up with some code that the others will find easy enough to hack
and contribute to, and then things will get going and we will be in
business.

I don't know exactly how this will happen, though, so until it does,
my own personal approach is just to offer all the support that I can
to anyone who seems interested in writing some code.  It doesn't
matter about the language or the platform or even the design -- if
they are actually doing some coding, then that seems to me to be a
positive thing.  You never know, they might come up with something
really good.  (And anyway, porting working code onto the other
platforms might make an interesting sub-project for someone later on,
if that's the way things turn out.)

I notice someone mentioned cloning BioExplorer [*].  This is an
interesting idea, because if you take a design that has already been
implemented once, then you know that all the software engineering
problems related to implementing that design are solvable -- the
working proof is there right in front of you.

This kind of approach has worked for other open-source projects.  For
example, the Linux kernel clones and improves upon the design of other
UNIX kernels, and KDE and GNOME in some senses clone and improve upon
Windows and the standard MS apps.  Letting someone else refine and
'prove' the design first can potentially save a whole load of trouble.

(It is not just open-source that borrows from commercial designs -- it
goes both ways, like Mac OSX incorporating loads of new ideas refined
in the open-source world, MS taking some Apple and open-source ideas,
and so on, and so on.  And like Linux vs UNIX and KDE vs Windows, the
cloned version often ends up quite different to the original.)

Alternatively, creating a new or independent design might mean a few
prototypes and rewrites along the way (and this is what I was more
interested in doing, although I'm really more of a back-end coder
myself).  Making a very rough comparison to all the previous EEG
devices designed for the OpenEEG project by Andreas, Joerg, Moritz and
so on, we could perhaps expect another couple of prototypes before we
hit on a software design that works well.  (But is this a fair
comparison?  I don't really know.)

So perhaps the choice is between trying to invent and implement a new
design never tried before (with a few prototypes and rewrites), or
cloning and improving upon an existing design (with maybe a rewrite at
some point if it doesn't work out well the first time), or maybe
taking some open-source project designed for some other purpose, and
reshaping it (Moritz's suggestion?).

There is also the ground-level magic of how to produce some code that
is accessible and fun for others to hack and improve on, which is
something I can't claim to have any answer to.  Maybe best to rely on
luck to deliver that.

It seems to me that the individual developers are the ones who should
be making the choices, because if they are not doing what they are
happy doing, then nothing much will actually happen.

So, I think that developers should totally ignore users for now and
get on with building whatever they are interested in, because that way
they will get much more done.  Users will have to make do with
whatever the developers come up with because we are all volunteers
here and trying to force people to do things probably just makes them
hide or disappear or whatever.

I'm not sure if this helps (or even if I am 100% correct), but maybe
this perspective can be useful ...

Jim

[* And actually there is someone doing some work along these lines,
although he hasn't spoken up yet. ]


P.S.  (The following is supposed to be funny).  Hmmmm, hardware people
designing software ... interesting.  Perhaps I should design a EEG
unit for you.  It should have:

- 8 channels for future expansion
- Daisy-chainable and upgradable to full QEEG if possible
- Modular self-testing design
- USB-based because that makes it most cross-platform
- Electrode impedence measurements built in, with LED indicators
- Active electrodes preferably
- Nice case
- Easy to build and test by novices
- Parts I can find in my local electronics store, if possible
- Environmentally friendly

I think that's everything.  I can draw a block diagram and define all
the requirements, and then all you have to do is fill in the boxes
with bits of electronic circuitry to make it work -- okay?  That
doesn't sound too hard.  Let me know how long you think it will take.

;-)

It is only because I have followed the development of the modularEEG
design that I know why some of the 'wish-list' items above are less
feasible in a reasonable time-span than others, and why many of them
are not present in the modularEEG. =20

Not knowing all the technicalities, I might easily design a hardware
cathedral and then be rather disappointed by the modest but usable
chapel that the team has actually managed to create.  That's not to
say that the team might not create a cathedral eventually one day,
though, or that some of the aims of the cathedral design might not be
achieved in some other way beyond the imagination of the cathedral's
designer (i.e. me).

Maybe the best thing users can do is write down lists of things that
they would like to achieve with their EEG unit software, without
trying to specify exactly how developers should implement these for
them.  I'm talking about the basic unadorned needs and wants.  I think
this kind of a 'wish-list' is the most likely to be useful and
inspiring to developers, if anything is -- IMHO.  (Some developer
please contradict me if they disagree).

There was never a huge external 'master plan' for the hardware
development, and surely the software development is more likely to
succeed on a similar basis -- i.e. based on a very short list of
flexible requirements and constraints.  (For example, for the hardware
it was something like: "EEG unit, <$100 if possible", and we are only
half-way to that goal.  Is this a failure then?  Not at all.)


P.P.S.  I am without internet access right now, having just moved to
Brighton, and sending E-mails means a trip to the beach to find a
wireless access point.  So forgive any delays.

--=20
 Jim Peters                  (_)/=3D\~/_(_)                 jim@...
                          (_)  /=3D\  ~/_  (_)
 Uaz=FA                  (_)    /=3D\    ~/_    (_)                http:/=
/
 Brighton, UK       (_) ____ /=3D\ ____ ~/_ ____ (_)            uazu.net

 Design/view/compare digital filters with Fiview:   http://uazu.net/FI

From: "Jim Peters" <jim@...>
> With respect, there is already some working open-source software in
> the form of EEGMIR and BWView -- and tons of developers have not
> jumped on board as a result.

Jim, I meant no disrespect to your excellent software.  I had forgotten
about it because BWView isn't real-time.  I just took a look at EEGMIR, and
it looks pretty cool, but it immediately started producing a scratchy
pulsating tone...  Is this normal?

I would love to be able to jump on board, but most of the filter stuff is
beyond me, I don't know anything about SDL or OpenGL, I haven't used GCC or
wine, and I haven't done cross-platform work.

I think portability is overrated, and developers should concentrate more on
making functions and libraries portable than trying to make whole apps
portable.  Most of the "portable" code that's out there looks more like a
Linux to windows port, than actually portable code.

I also think we should stay away from bastard languages, like C# and .Net,
in the interest of making progress rather than fragmenting the effort.

-Jake

Jim
I originally posted this Why?? thread because it intrigued me that you had 
taken this so far with bwview and eegmir and fiview, and am interesting in 
seeing it go further. But maybe we should have where?? and how??, along 
with the original why??.


At 09:29 AM 12/16/2003 +0000, you wrote:
>Jake wrote:
> > I think that somebody needs to "step up to the plate" and release
> > open source, working software.  Once this happens tons of developers
> > will jump on board because it is far easier to modify working code
> > than to start from scratch.  Even average users of the software can
> > jump in and make small modifications to suit their purposes.
>
>With respect, there is already some working open-source software in
>the form of EEGMIR and BWView -- and tons of developers have not
>jumped on board as a result.
>
>   http://uazu.net/bwview/
>   http://uazu.net/eegmir/
>
>Maybe we simply don't have enough developers with working modEEGs and
>an itch that they need to scratch to get the ball rolling quite yet.
>(Or maybe they all have different itches.)
>
>However, someday there will be enough developers, and someone will
>come up with some code that the others will find easy enough to hack
>and contribute to, and then things will get going and we will be in
>business.

We have interested developers but each seems to have a different slant, and 
a different approach, and there is little consensus, so little 
collaboration. Maybe the software field is naturally more competitive than 
cooperative, or collaborative.

>I don't know exactly how this will happen, though, so until it does,
>my own personal approach is just to offer all the support that I can
>to anyone who seems interested in writing some code.  It doesn't
>matter about the language or the platform or even the design -- if
>they are actually doing some coding, then that seems to me to be a
>positive thing.  You never know, they might come up with something
>really good.  (And anyway, porting working code onto the other
>platforms might make an interesting sub-project for someone later on,
>if that's the way things turn out.)
>
>I notice someone mentioned cloning BioExplorer [*].  This is an
>interesting idea, because if you take a design that has already been
>implemented once, then you know that all the software engineering
>problems related to implementing that design are solvable -- the
>working proof is there right in front of you.

I think folk should be aware that Larry Yanow who wrote BioExplorer is also 
a participant on this list, so any reference to his design is somewhat 
sensitive. (Hi Larry).

>This kind of approach has worked for other open-source projects.  For
>example, the Linux kernel clones and improves upon the design of other
>UNIX kernels, and KDE and GNOME in some senses clone and improve upon
>Windows and the standard MS apps.  Letting someone else refine and
>'prove' the design first can potentially save a whole load of trouble.
>
>(It is not just open-source that borrows from commercial designs -- it
>goes both ways, like Mac OSX incorporating loads of new ideas refined
>in the open-source world, MS taking some Apple and open-source ideas,
>and so on, and so on.  And like Linux vs UNIX and KDE vs Windows, the
>cloned version often ends up quite different to the original.)
>
>Alternatively, creating a new or independent design might mean a few
>prototypes and rewrites along the way (and this is what I was more
>interested in doing, although I'm really more of a back-end coder
>myself).  Making a very rough comparison to all the previous EEG
>devices designed for the OpenEEG project by Andreas, Joerg, Moritz and
>so on, we could perhaps expect another couple of prototypes before we
>hit on a software design that works well.  (But is this a fair
>comparison?  I don't really know.)

Yes, I think this is a very fair comparison. After all engineering is 
engineering and obeys the same priniples.

>So perhaps the choice is between trying to invent and implement a new
>design never tried before (with a few prototypes and rewrites), or
>cloning and improving upon an existing design (with maybe a rewrite at
>some point if it doesn't work out well the first time), or maybe
>taking some open-source project designed for some other purpose, and
>reshaping it (Moritz's suggestion?).
>
>There is also the ground-level magic of how to produce some code that
>is accessible and fun for others to hack and improve on, which is
>something I can't claim to have any answer to.  Maybe best to rely on
>luck to deliver that.
>
>It seems to me that the individual developers are the ones who should
>be making the choices, because if they are not doing what they are
>happy doing, then nothing much will actually happen.
>
>So, I think that developers should totally ignore users for now and
>get on with building whatever they are interested in, because that way
>they will get much more done.  Users will have to make do with
>whatever the developers come up with because we are all volunteers
>here and trying to force people to do things probably just makes them
>hide or disappear or whatever.
>
>I'm not sure if this helps (or even if I am 100% correct), but maybe
>this perspective can be useful ...
>
>Jim
>
>[* And actually there is someone doing some work along these lines,
>although he hasn't spoken up yet. ]
>
>
>P.S.  (The following is supposed to be funny).  Hmmmm, hardware people
>designing software ... interesting.  Perhaps I should design a EEG
>unit for you.  It should have:
>
>- 8 channels for future expansion
>- Daisy-chainable and upgradable to full QEEG if possible
>- Modular self-testing design
>- USB-based because that makes it most cross-platform
>- Electrode impedence measurements built in, with LED indicators
>- Active electrodes preferably
>- Nice case
>- Easy to build and test by novices
>- Parts I can find in my local electronics store, if possible
>- Environmentally friendly
>
>I think that's everything.  I can draw a block diagram and define all
>the requirements, and then all you have to do is fill in the boxes
>with bits of electronic circuitry to make it work -- okay?  That
>doesn't sound too hard.  Let me know how long you think it will take.

Jim..yes it is funny..because it so precise. Without sometime knowing it we 
actually do that. make the boxes and fill in the contents. to get ModEEG 
done you had to have a Input amp, a filter amp, an A/D digitiser with code, 
a voltage barrier, a RS232 device, a VGND system, a DRL system etc. Each of 
these boxes had various options but eventually they all became one single 
modular thing. Modular is important imo.

ScEEG has its own modules, that replace the A/D digitiser and RS232 with an 
FM Modulator, but still use the analog modules from OpenEEG.

Isn't software also modular. I thought the classes defined the various 
modules. Don't these modules have inputs and outputs just like all systems do.


>It is only because I have followed the development of the modularEEG
>design that I know why some of the 'wish-list' items above are less
>feasible in a reasonable time-span than others, and why many of them
>are not present in the modularEEG.

Good point



>Not knowing all the technicalities, I might easily design a hardware
>cathedral and then be rather disappointed by the modest but usable
>chapel that the team has actually managed to create.  That's not to
>say that the team might not create a cathedral eventually one day,
>though, or that some of the aims of the cathedral design might not be
>achieved in some other way beyond the imagination of the cathedral's
>designer (i.e. me).

This catherdral and bazzar idea is so relevant and important, and should 
not be ignored. As you say, cathedral translates to 'wish list', and needs 
to be related to 'acheivable'.


>Maybe the best thing users can do is write down lists of things that
>they would like to achieve with their EEG unit software, without
>trying to specify exactly how developers should implement these for
>them.  I'm talking about the basic unadorned needs and wants.  I think
>this kind of a 'wish-list' is the most likely to be useful and
>inspiring to developers, if anything is -- IMHO.  (Some developer
>please contradict me if they disagree).

I will write something explaining my personal needs, without going into 
implementations or such. Maybe that will help. It may take a day or two, 
but I will do that. But it means moving to an even higher level of view, 
but that's OK by me.

>There was never a huge external 'master plan' for the hardware
>development, and surely the software development is more likely to
>succeed on a similar basis -- i.e. based on a very short list of
>flexible requirements and constraints.  (For example, for the hardware
>it was something like: "EEG unit, <$100 if possible", and we are only
>half-way to that goal.  Is this a failure then?  Not at all.)

Who said anything about failure. Its a total success.!!

Jim..one thing that has come out of this, for me, is that it is very easy 
to offend people. I never intended that. Sorry if I did. Maybe I am 'over 
eager' as someone pointed out, or simply grandiose, who knows. But rest 
assured, I am very interested in what may come out of this, and am very 
optimistic. You guys are legend.

Modular has to be the key to solving this, as it was with ModEEG.

Ian

Well, since nobody has any ideas about how I can easily get an Atmega8
based ModularEEG, what do people think of starting by making
firmware geared only for the older processor?  Jake has already suggested
it's not so good but it seems the only choice.  Would it be a big waste
of my time? Or would it be not much trouble to port to Atmega8 whenever the
hardware is ready?  My impression is the AVR core is fairly consistent
but I have no experience.  Would it be possible for me to upgrade my
ModularEEG to an Atemga8 when the right package (PDIP I guess) Atmega8 
becomes available?  Or would I wind up having to buy a whole new digital
board would you guess?  I'm anxious to get started, what with Christmas
sneaking up on us and all.... Have a Merry one,

Rudi

Rudi,

who told you that modularEEG board doesn't support Atmega8 processor?
I though it does (but I am not authority about that) and that the only significant
hardware difference was that channel 5 and 6 are 8-bit, not 10-bit as before.
Of course the firmware would have to be compiled for Atmega8, but is there anything else
that is not compatible?

thanks
Jarek


> Hi again everybody,
> 
> I've been exchanging emails with Jake and Moritz, and would like to get
> started on some of the software development tasks at hand.  I have
> contacted Olimex about buying a ModularEEG, but unfortunately there are
> two problems that prevent me from ordering:
> 
> 1) It doesn't support the Atmega8 processor, which Jake has told me is
> the more up-to-date.  I don't want to develop software for an obsolete
> chip.
> 
> 2) It doesn't include a programming cable, and the company can't make one.
> 
> Unfortunately, I'm terrible with a soldering iron (I use wire-wrap and
> only build digital) and so this is a hurdle.  Can somebody give me some
> suggestion about how I might get a working platform here with programming
> capability on an Atmega 8?  I think the electrodes can be put off until 
> the software is a little more developed.
> 
> I'm enthusiastic to get started as I really enjoyed writing firmware
> the last time I did it in school and would love to help with this exciting
> project.  I've reviewed the basic and bidirectional firmware code that
> we already have and have reported the one potential bug I found to
> Moritz, but now I'm really stuck without a working platform to play
> with.
> 
> Thanks for any pointers,
> 
> Rudi
> 
> On Sat, Dec 13, 2003 at 08:33:15AM +1300, Ian Vincent wrote:
> > Hi there and Why? there
> > 
> > I know it is a very childish thing to ask 'why', but I am going to ask 
> > anyway because I simply don't understand. I hope no one takes this as a 
> > personal criticism, they are only my comments, and thoughts around software.
> > 
> > Why is it that this project has had numerous attempts at software projects 
> > that seem to get started and then go so far, then stop. Is it a feature of 
> > software authoring, that the author gets bored or distracted and moves onto 
> > other projects.
> > 
> > Or is it that the Author under estimates the time it takes, and eventually 
> > other priorities crop up.
> > 
> > Or is it that its so damn complex that the author gets lost.
> > 
> > Or is it that the Author loses interest.
> > 
> > Or is it something else all together.
> > 
> > Or is it that Software is endless in itself.
> > 
> > Being a hardware guy, I used to envy software guys because of their ability 
> > to work together collaboratively over the internet, sharing code and ideas, 
> > etc. I thought this was something that Hardware guys couldn't actually do. 
> > But the evidence from this OpenEEG project is just the opposite to what I 
> > used to think. The Hardware seems to evolve spontaneously, with intense 
> > levels of interest, and the posting back and forward of spice models and 
> > text and PCB designs, and out of the end pops a proffesional PCB that does 
> > the job.
> > 
> > So what's happening with the software. Is it more difficult to work 
> > collaboratively. Are there so many variables and combinations and 
> > permutations that it gets sidetracked or what. I don't recall any details 
> > of the inner workings of the various project softwares posted here. No 
> > plans or sketches or models or flow diagrams or such. So how would there 
> > ever be collaboration if there is nothing of this nature. I have seen some 
> > code that I don't understand because I don't do code, so cant use. I also 
> > have BioExplorer that I can't see the code but can use. As an Opensource 
> > project we need installable code that actually does something, yet has 
> > opensource.  It seems to be about how to define what the 'does something' 
> > actually is, before the coding starts, perhaps.
> > 
> > How an we improve this situation. What is the norm for collaborative 
> > software development. Are there tools out there for use in this area, or 
> > are these tools so complex that they become there own project.
> > 
> > What I think is needed is a fresh start, a new approach, an over all plan, 
> > a collaborative software project. Now that we have a reliable and stable 
> > hardware platform, ie modEEG,  this is possible. It opens the gate to 
> > software developers and we might now see some sustained progress. I am sure 
> > in the past the sheer time involved in getting a EEG device functioning 
> > provided enough alligators to ever prevent the swamp being cleared.
> > 
> > How do we do this guys. How can I help. How can we keep this flexible, and 
> > open, and evolving into the future. How do we guaruntee that the project 
> > will end up with a working software at the end of all of this.
> > 
> > What happened to the object library.?? and where is it defined. Can it be 
> > used or is it old and crusty.
> > 
> > Ian
> > 
> > 
> > 
> > -------------------------------------------------------
> > This SF.net email is sponsored by: SF.net Giveback Program.
> > Does SourceForge.net help you be more productive?  Does it
> > help you create better code?  SHARE THE LOVE, and help us help
> > YOU!  Click Here: http://sourceforge.net/donate/
> > _______________________________________________
> > Openeeg-list mailing list
> > Openeeg-list@...
> > https://lists.sourceforge.net/lists/listinfo/openeeg-list
> > Go to the above address to change your
> > subscription options, e.g unsubscribe.
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: SF.net Giveback Program.
> Does SourceForge.net help you be more productive?  Does it
> help you create better code?  SHARE THE LOVE, and help us help
> YOU!  Click Here: http://sourceforge.net/donate/
> _______________________________________________
> Openeeg-list mailing list
> Openeeg-list@...
> https://lists.sourceforge.net/lists/listinfo/openeeg-list
> Go to the above address to change your
> subscription options, e.g unsubscribe.

I have an ATMega8 in my ModEEG and it works fine. The firmware is available.

Ian


At 01:31 PM 12/16/2003 -0800, you wrote:
>Well, since nobody has any ideas about how I can easily get an Atmega8
>based ModularEEG, what do people think of starting by making
>firmware geared only for the older processor?  Jake has already suggested
>it's not so good but it seems the only choice.  Would it be a big waste
>of my time? Or would it be not much trouble to port to Atmega8 whenever the
>hardware is ready?  My impression is the AVR core is fairly consistent
>but I have no experience.  Would it be possible for me to upgrade my
>ModularEEG to an Atemga8 when the right package (PDIP I guess) Atmega8
>becomes available?  Or would I wind up having to buy a whole new digital
>board would you guess?  I'm anxious to get started, what with Christmas
>sneaking up on us and all.... Have a Merry one,
>
>Rudi
>
>
>
>-------------------------------------------------------
>This SF.net email is sponsored by: IBM Linux Tutorials.
>Become an expert in LINUX or just sharpen your skills.  Sign up for IBM's
>Free Linux Tutorials.  Learn everything from the bash shell to sys admin.
>Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
>_______________________________________________
>Openeeg-list mailing list
>Openeeg-list@...
>https://lists.sourceforge.net/lists/listinfo/openeeg-list
>Go to the above address to change your
>subscription options, e.g unsubscribe.

Hi,

Rudi Cilibrasi wrote:
> Hi again everybody,
> 
> I've been exchanging emails with Jake and Moritz, and would like to get
> started on some of the software development tasks at hand.  I have
> contacted Olimex about buying a ModularEEG, but unfortunately there are
> two problems that prevent me from ordering:
> 
> 1) It doesn't support the Atmega8 processor,

It does!

> which Jake has told me is
> the more up-to-date.  I don't want to develop software for an obsolete
> chip.
> 
> 2) It doesn't include a programming cable, and the company can't make one.


Did Olimex tell you, that they do not have the programming cable?

That is funny...


The digital board # V0.7, V1.0 and higher requires a parallel port programming 
adapter cable with 10 poles as described in V0.7, V1.0 "cables.sch" (eagle file)

_or_

* the OLIMEX parallel programming adapter (AVR-PG2B (PARALLEL PORT) 10 PIN ICSP 
AVR MICROCONTROLLER PROGRAMMER)
http://www.olimex.com/dev/avr-pg2b.html


Regards,

	Joerg

On Thu, Dec 18, 2003 at 01:21:40AM +0100, Joerg Hansmann wrote:
> Hi,
> 
> Rudi Cilibrasi wrote:
> >Hi again everybody,
> >
> >I've been exchanging emails with Jake and Moritz, and would like to get
> >started on some of the software development tasks at hand.  I have
> >contacted Olimex about buying a ModularEEG, but unfortunately there are
> >two problems that prevent me from ordering:
> >
> >1) It doesn't support the Atmega8 processor,
> 
> It does!

Ok ... Let me clarify; I emailed Olimex to ask if I could get a ModEEG
with an Atmega8 processor and he said it was impossible because he
couldn't get Atmega8 in the right type of package.  I guess I'm supposed
to order the processor seperately and upgrade it myself then?

> >which Jake has told me is
> >the more up-to-date.  I don't want to develop software for an obsolete
> >chip.
> >
> >2) It doesn't include a programming cable, and the company can't make one.
> Did Olimex tell you, that they do not have the programming cable?

I finally figured out that I misunderstood Olimex' response on this question.
In any case I've ordered both the serial and parallel programming cables
as well as the ModEEG so I should be able to fool around with this during
the holidays.  I will let the list know if I manage to get anything useful
going.  Cheers,

Rudi
> 
> That is funny...
> 
> 
> The digital board # V0.7, V1.0 and higher requires a parallel port 
> programming adapter cable with 10 poles as described in V0.7, V1.0 
> "cables.sch" (eagle file)
> 
> _or_
> 
> * the OLIMEX parallel programming adapter (AVR-PG2B (PARALLEL PORT) 10 PIN 
> ICSP AVR MICROCONTROLLER PROGRAMMER)
> http://www.olimex.com/dev/avr-pg2b.html
> 
> 
> Regards,
> 
> 	Joerg
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: IBM Linux Tutorials.
> Become an expert in LINUX or just sharpen your skills.  Sign up for IBM's
> Free Linux Tutorials.  Learn everything from the bash shell to sys admin.
> Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
> _______________________________________________
> Openeeg-list mailing list
> Openeeg-list@...
> https://lists.sourceforge.net/lists/listinfo/openeeg-list
> Go to the above address to change your
> subscription options, e.g unsubscribe.

Ian Vincent wrote:
> We have interested developers but each seems to have a different
> slant, and a different approach, and there is little consensus, so
> little collaboration.  Maybe the software field is naturally more
> competitive than cooperative, or collaborative.

I think when we find the right approach (i.e. when someone comes up
with some convincing piece of working software with source code that
obviously 'clicks'), everybody will be on board.

At least, it was like that with the project logo -- as soon as
everyone at the time saw it, they said, "Yes, great!  Let's use it."


> >I notice someone mentioned cloning BioExplorer [*].  This is an
> >interesting idea, because if you take a design that has already
> >been implemented once, then you know that all the software
> >engineering problems related to implementing that design are
> >solvable -- the working proof is there right in front of you.
>=20
> I think folk should be aware that Larry Yanow who wrote BioExplorer
> is also a participant on this list, so any reference to his design
> is somewhat sensitive. (Hi Larry).

I was attempting to comment on the difference between creating a
design out of thin air, which might require some serious rethinking
during implementation, and basing a design on something known that is
tried and tested, i.e. that already exists and is examinable.

I haven't tried BioExplorer, but it sounds like a very polished
package.  Duplicating that would probably be serious work.  As to the
sensitivity of talking about it with the author listening: "Imitation
is the sincerest form of flattery"!  Should we go out of our way *not*
to make something very similar in functionality, just out of
politeness?  I don't think so.

Rather the point I was trying to make was that looking closely at
something similar that already works can help resolve a lot of
questions during implementation that might be stumbling blocks
otherwise.


> Jim..yes it is funny..because it so precise. Without sometime
> knowing it we actually do that. make the boxes and fill in the
> contents. to get ModEEG done you had to have a Input amp, a filter
> amp, an A/D digitiser with code, a voltage barrier, a RS232 device,
> a VGND system, a DRL system etc. Each of these boxes had various
> options but eventually they all became one single modular
> thing. Modular is important imo.

Yes, and the constraints on each notional 'box' in the modularEEG
design were modified to fit well with the others, from one version to
the next.  The internal constraints were not set once in a master
design, and then kept constant for the whole project.

Okay, I admit that for electronics you are more interested in
optimising out everything right to the limit, whereas with software
the relative costs are different (i.e. source code size, executable
size and speed of execution can all be a very long way from 'optimal'
without affecting the usability of the resulting application), but
still I think the same applies to some extent.

That was the thing that bothered me -- a vast and comprehensive design
created with little understanding of the ground-level technicalities.
If that was a fixed target, then there will be problems, guaranteed.
If it is taken only as a 'wish-list' to aim for with some flexibility,
then that is far more realistic.


> Isn't software also modular. I thought the classes defined the
> various modules. Don't these modules have inputs and outputs just
> like all systems do.

How you structure things at the ground level, both in the program and
data flow and within the source code (functions/classes/etc), can have
significant side-effects on the rest of the design, i.e. on what is
easy to do and what is hard to do later on.

How to get it right -- I don't know the answer myself.  But I think we
will be able to recognise when someone comes up with a good working
approach.

(I think I am too low-level a programmer to get this right -- I tend
towards "premature optimization", i.e. getting everything optimized
right away even when not strictly necessary (for example, the
experimental JIT ix86 compiler I wrote for the filters in fidlib).  I
admit that this is not too healthy an approach for general
programming, but still I think that completely ignoring lower-level
issues can cause just as much trouble.)


> This catherdral and bazzar idea is so relevant and important, and
> should not be ignored. As you say, cathedral translates to 'wish
> list', and needs to be related to 'acheivable'.

Yes, definitely.


> I will write something explaining my personal needs, without going
> into implementations or such. Maybe that will help. It may take a
> day or two, but I will do that. But it means moving to an even
> higher level of view, but that's OK by me.

The point I was trying to make was that people sometimes think that
they want something, for example, "a car", but in fact all it is is
that they perceive that "a car" will answer some need that they have.
They might become fixated on "a car", but fail to realize that some
other solution might actually work a lot better.

Keeping closer to the real needs allows for the possibility for other
innovative solutions from unexpected directions.  (I mean, your
multi-pin electrode idea is fantastic -- why didn't I think of that?)

Still, maybe it is sometimes better just to go and buy "a car" and
find out the hard way whether or not it is really going to solve the
problem.  At least then you know.


> >There was never a huge external 'master plan' for the hardware
> >development, and surely the software development is more likely to
> >succeed on a similar basis -- i.e. based on a very short list of
> >flexible requirements and constraints.  (For example, for the hardware
> >it was something like: "EEG unit, <$100 if possible", and we are only
> >half-way to that goal.  Is this a failure then?  Not at all.)
>=20
> Who said anything about failure. Its a total success.!!

If I make a "grand EEG hardware plan" and compare the current modEEG
to the plan, it looks like the project has achieved nothing -- maybe
only 10% success.  That is what is intimidating about your grand
design.  It makes my heart sink reading it.  I read a line of text and
imagine the several hundred lines of code required to implement it.

I guess this is just my response to this, based on my own personal
history of making grand software plans and finding out the hard way
that they were too big for me to implement.  Perhaps others don't have
quite the same history, and maybe could negotiate the potential
implementation problems that I can see with less difficulty -- in
which case my contribution to the discussion is not really needed.


> Jim..one thing that has come out of this, for me, is that it is very
> easy to offend people. I never intended that. Sorry if I did.=20

No offense taken at all -- just my perception that some balance is
required.


> Maybe I am 'over eager' as someone pointed out, or simply grandiose,
> who knows. But rest assured, I am very interested in what may come
> out of this, and am very optimistic. You guys are legend.

Yes, there do seem to be quite a few new people around.  I'll back off
from the discussion and leave it to those who are more actively
developing ideas and code.

Jim

--=20
 Jim Peters                  (_)/=3D\~/_(_)                 jim@...
                          (_)  /=3D\  ~/_  (_)
 Uaz=FA                  (_)    /=3D\    ~/_    (_)                http:/=
/
 Brighton, UK       (_) ____ /=3D\ ____ ~/_ ____ (_)            uazu.net

 OpenEEG -- EEG for the rest of us!   For details:  http://uazu.net/OE

Jake wrote:
> I had forgotten about it because BWView isn't real-time.  I just
> took a look at EEGMIR, and it looks pretty cool, but it immediately
> started producing a scratchy pulsating tone...  Is this normal?

Yes, I was experimenting with a form of audio feedback in the last
version.

Jim

--=20
 Jim Peters                  (_)/=3D\~/_(_)                 jim@...
                          (_)  /=3D\  ~/_  (_)
 Uaz=FA                  (_)    /=3D\    ~/_    (_)                http:/=
/
 Brighton, UK       (_) ____ /=3D\ ____ ~/_ ____ (_)            uazu.net

 BWView: a fast visual browser for brainwave files: http://uazu.net/BW

At 04:49 PM 12/20/2003 +0000, you wrote:


> > >I notice someone mentioned cloning BioExplorer [*].  This is an
> > >interesting idea, because if you take a design that has already
> > >been implemented once, then you know that all the software
> > >engineering problems related to implementing that design are
> > >solvable -- the working proof is there right in front of you.
> >
> > I think folk should be aware that Larry Yanow who wrote BioExplorer
> > is also a participant on this list, so any reference to his design
> > is somewhat sensitive. (Hi Larry).
>
>I was attempting to comment on the difference between creating a
>design out of thin air, which might require some serious rethinking
>during implementation, and basing a design on something known that is
>tried and tested, i.e. that already exists and is examinable.
>
>I haven't tried BioExplorer, but it sounds like a very polished
>package.  Duplicating that would probably be serious work.  As to the
>sensitivity of talking about it with the author listening: "Imitation
>is the sincerest form of flattery"!  Should we go out of our way *not*
>to make something very similar in functionality, just out of
>politeness?  I don't think so.
>
>Rather the point I was trying to make was that looking closely at
>something similar that already works can help resolve a lot of
>questions during implementation that might be stumbling blocks
>otherwise.

True. But we need to have something original, not just a clone of BE. But 
you are right, it does provide a conceptual guide. Someone suggested asking 
Larry to make his code open source, that would solve us a lot of headache. 
Can't see it happening tho. What I like about BE is that it was totally 
natural to use, and that is because it follows a natural design paradigm, 
so we need to learn from that. Concepts such as Filter and Threshold are 
natural concepts imo, and not exclusive to BE.

> > Jim..yes it is funny..because it so precise. Without sometime
> > knowing it we actually do that. make the boxes and fill in the
> > contents. to get ModEEG done you had to have a Input amp, a filter
> > amp, an A/D digitiser with code, a voltage barrier, a RS232 device,
> > a VGND system, a DRL system etc. Each of these boxes had various
> > options but eventually they all became one single modular
> > thing. Modular is important imo.
>
>Yes, and the constraints on each notional 'box' in the modularEEG
>design were modified to fit well with the others, from one version to
>the next.  The internal constraints were not set once in a master
>design, and then kept constant for the whole project.
>
>Okay, I admit that for electronics you are more interested in
>optimising out everything right to the limit, whereas with software
>the relative costs are different (i.e. source code size, executable
>size and speed of execution can all be a very long way from 'optimal'
>without affecting the usability of the resulting application), but
>still I think the same applies to some extent.
>
>That was the thing that bothered me -- a vast and comprehensive design
>created with little understanding of the ground-level technicalities.
>If that was a fixed target, then there will be problems, guaranteed.
>If it is taken only as a 'wish-list' to aim for with some flexibility,
>then that is far more realistic.

The 'notional box' I like it. I see a direct correlation between hardware 
and software design that inherit from their common engineering roots, And a 
modular, 'notional box' design is part of that. In particular I like the 
way the oop paradigm mimics natural organisation, so it is natural for me 
to work at the notional box level.

Interfacing is a subject common to hardware designs and oop designs, though 
the approach is different. Conceptually it is the same thing and involves 
two seperate entities communicating with each other. In the hardware the 
interfaces occur between the various IC's but also between the analogue and 
digital boards, and between the digital board and the PC.

Using the VBA editor with various automation engines taught me that this 
'notional box' design extends down into the language, and so into the code 
itself. Basically it is everywhere so why not just assume it and use it. 
That's my take on it anyway. (no I don't like VBA particularly but it is 
very convenient for me sometimes)

> > Isn't software also modular. I thought the classes defined the
> > various modules. Don't these modules have inputs and outputs just
> > like all systems do.
>
>How you structure things at the ground level, both in the program and
>data flow and within the source code (functions/classes/etc), can have
>significant side-effects on the rest of the design, i.e. on what is
>easy to do and what is hard to do later on.
>
>How to get it right -- I don't know the answer myself.  But I think we
>will be able to recognise when someone comes up with a good working
>approach.
>
>(I think I am too low-level a programmer to get this right -- I tend
>towards "premature optimization", i.e. getting everything optimized
>right away even when not strictly necessary (for example, the
>experimental JIT ix86 compiler I wrote for the filters in fidlib).  I
>admit that this is not too healthy an approach for general
>programming, but still I think that completely ignoring lower-level
>issues can cause just as much trouble.)

Jim..I come at software from the high level RAD side of things, so 
effectively we are at the opposite end of the continuim. But imo it is very 
important to recognise this. That the continuim does have two ends and that 
each end is important. In some sense that is what this topic has been 
about. I have huge respect for low level coders, and less respect for top 
end designers. High level is far easier, but it still has its place in the 
grand scheme of things. Low level requires a much higher level of skill imo 
and ime. That's why I stick to the top end.

> > This catherdral and bazzar idea is so relevant and important, and
> > should not be ignored. As you say, cathedral translates to 'wish
> > list', and needs to be related to 'acheivable'.
>
>Yes, definitely.
>
>
> > I will write something explaining my personal needs, without going
> > into implementations or such. Maybe that will help. It may take a
> > day or two, but I will do that. But it means moving to an even
> > higher level of view, but that's OK by me.
>
>The point I was trying to make was that people sometimes think that
>they want something, for example, "a car", but in fact all it is is
>that they perceive that "a car" will answer some need that they have.
>They might become fixated on "a car", but fail to realize that some
>other solution might actually work a lot better.

I agree totally with this, which is why cloning BE is OK, but not the best 
focus. I am trying to keep focused on NFB delivery, in the community, 
rather than the  devices or code, but in the end the code must match the 
delivery paradigm, and achieving this is the job of the top end design. imo.

>Keeping closer to the real needs allows for the possibility for other
>innovative solutions from unexpected directions.  (I mean, your
>multi-pin electrode idea is fantastic -- why didn't I think of that?)

Thanks, it does have a certain elegant simplicity, I must admit, but it is 
so simple that it doesn't rate in engineering terms.


>Still, maybe it is sometimes better just to go and buy "a car" and
>find out the hard way whether or not it is really going to solve the
>problem.  At least then you know.

k..so that's why I shelled out for BE..;-)

> > >There was never a huge external 'master plan' for the hardware
> > >development, and surely the software development is more likely to
> > >succeed on a similar basis -- i.e. based on a very short list of
> > >flexible requirements and constraints.  (For example, for the hardware
> > >it was something like: "EEG unit, <$100 if possible", and we are only
> > >half-way to that goal.  Is this a failure then?  Not at all.)
> >
> > Who said anything about failure. Its a total success.!!
>
>If I make a "grand EEG hardware plan" and compare the current modEEG
>to the plan, it looks like the project has achieved nothing -- maybe
>only 10% success.  That is what is intimidating about your grand
>design.  It makes my heart sink reading it.  I read a line of text and
>imagine the several hundred lines of code required to implement it.

Intimidating, is that why I got so much negative response. It was purely a 
reflection of my needs, a wish list. but i see what you mean and am sure 
that I would react the same way if I was in your shoes. ModEEG is totally 
adequate for my needs btw. It does the job, cheap, has adequate performance.

What is your 'grand EEG hardware plan', I would be interested to see it.??

>I guess this is just my response to this, based on my own personal
>history of making grand software plans and finding out the hard way
>that they were too big for me to implement.  Perhaps others don't have
>quite the same history, and maybe could negotiate the potential
>implementation problems that I can see with less difficulty -- in
>which case my contribution to the discussion is not really needed.

Jim, you are singulary the most productive software guy on this list, and 
probably know more about what's going on at the low levels than anyone else 
I expect. You have produced several EEG apps and a filter designer that are 
all great tools but they don't provide someone with NFB delivery functions. 
That is is not what they where designed to do, obviously. However the 
technology that they incorporate is what is needed as components in a wider 
scheme that can deliver NFB function.

On the other hand, I am just a self taught wannabe software hacker that 
needs an NFB app and who innocently thought that laying out plans for a 
grand object set might be the way to go about achieving it, or at least 
kicking some life into something that could end up as something useable. I 
still believe it is the wtg and am acting on it. The low level code that 
you know so well, is only needed in a couple of the objects, the rest can 
be handled at a much higher level, so I don't really see the issue. Isn't 
this the very nature of specialisation and of collaboration. We each have 
our place. does the car painter also do tyres. I think not.


> > Maybe I am 'over eager' as someone pointed out, or simply grandiose,
> > who knows. But rest assured, I am very interested in what may come
> > out of this, and am very optimistic. You guys are legend.
>
>Yes, there do seem to be quite a few new people around.  I'll back off
>from the discussion and leave it to those who are more actively
>developing ideas and code.

Why back off..have you lost interest? I have a gut feeling that most of the 
low level stuff that we need, you have at your finger tips already, and 
that you could play a pivotal role with regard to filter design and 
interfacing to ModEEG. These are totally critical elements, and need the 
highest level of expertise. The rest is easy in comparison, even if there 
is more of it.

Ian

Ian Vincent wrote:
> Using the VBA editor with various automation engines taught me that
> this 'notional box' design extends down into the language, and so
> into the code itself. Basically it is everywhere so why not just
> assume it and use it.  That's my take on it anyway.

The point is that you can start out with one 'notional box' design,
start implementing it, find it isn't working out too well, have some
more ideas, and then try out another 'notional box' design.  That is
the design-implementation process, as I see it at least.


> Jim..I come at software from the high level RAD side of things, so
> effectively we are at the opposite end of the continuim. But imo it
> is very important to recognise this. That the continuim does have
> two ends and that each end is important. In some sense that is what
> this topic has been about. I have huge respect for low level coders,
> and less respect for top end designers. High level is far easier,
> but it still has its place in the grand scheme of things. Low level
> requires a much higher level of skill imo and ime. That's why I
> stick to the top end.

I think I too can do high-level design, but the part that I am missing
is the middle-level part that connects low-level and high-level.
Hopefully there are other people around who can manage this. =20

(For me, working with code is like zooming into a fractal -- the
closer I look, the more questions there are to deal with, and looking
at those questions reveals yet more questions, and so on, and so on;
how to stay half-way between looking at the high-level design and
diving fractal-like into the low-level detail is a trick I haven't
learnt yet.)

We need a good middle-level design -- one that doesn't give *too* much
attention to all the finer points of optimization, and yet that
enables all the higher-level things to be implemented.  It also needs
to be fairly natural to code in the chosen implementation language
(i.e. so you are not fighting with the language all the time).

That is what I think we need.


> >(I mean, your multi-pin electrode idea is fantastic -- why didn't I
> >think of that?)
>=20
> Thanks, it does have a certain elegant simplicity, I must admit, but
> it is so simple that it doesn't rate in engineering terms.

It is simple once you have already seen it, but not at all simple
before then!  Getting to that point requires some inspiration, and
then some experimentation to prove it.  The question, in software
terms, is who the required inspiration is going to land on, and who is
going to act on it and make it work!  ;-)


> >If I make a "grand EEG hardware plan" and compare the current modEEG
> >to the plan, it looks like the project has achieved nothing -- maybe
> >only 10% success.  That is what is intimidating about your grand
> >design.  It makes my heart sink reading it.  I read a line of text and
> >imagine the several hundred lines of code required to implement it.
>=20
> Intimidating, is that why I got so much negative response. It was
> purely a reflection of my needs, a wish list. but i see what you
> mean and am sure that I would react the same way if I was in your
> shoes. ModEEG is totally adequate for my needs btw. It does the job,
> cheap, has adequate performance.
>=20
> What is your 'grand EEG hardware plan', I would be interested to see
> it.??

I don't want to even start dreaming one up!!  It would be a waste of
time from my point of view.  Instead, focussing on direct needs, if I
can get some electrodes working reliably so that I can do sessions on
myself, probably using the new impedence measurement add-on to verify
that everything is working fine, all that and the current modEEG
hardware will do the job very well.  After that, we'll see how things
look.  Maybe there would be more things required in hardware later on,
or maybe not.


> Jim, you are singulary the most productive software guy on this
> list, and probably know more about what's going on at the low levels
> than anyone else I expect. You have produced several EEG apps and a
> filter designer that are all great tools but they don't provide
> someone with NFB delivery functions.  That is is not what they where
> designed to do, obviously.=20

I was trying to prepare the ground, to get some basic tools and
libraries in place, and to get a good understanding for myself of the
dynamics of signals at brain-wave frequencies.


> However the technology that they incorporate is what is needed as
> components in a wider scheme that can deliver NFB function.
>
> On the other hand, I am just a self taught wannabe software hacker
> that needs an NFB app and who innocently thought that laying out
> plans for a grand object set might be the way to go about achieving
> it, or at least kicking some life into something that could end up
> as something useable.  I still believe it is the wtg and am acting
> on it.

Certainly, trying to do something is surely better than complaining.


> The low level code that you know so well, is only needed in a couple
> of the objects, the rest can be handled at a much higher level, so I
> don't really see the issue. Isn't this the very nature of
> specialisation and of collaboration. We each have our place. does
> the car painter also do tyres. I think not.

Yes, if someone can fill in the rest of the parts of the puzzle, then
that would be great.


> Why back off..have you lost interest? I have a gut feeling that most
> of the low level stuff that we need, you have at your finger tips
> already, and that you could play a pivotal role with regard to
> filter design and interfacing to ModEEG. These are totally critical
> elements, and need the highest level of expertise. The rest is easy
> in comparison, even if there is more of it.

I do still very much believe in the OpenEEG project, and I'm happy to
help put filter-related stuff into anyone's NFB app.  ("You want a
scrolling BWView-style display?  We have the technology!").

However, I have a lot less time now than I did.  I'm taking a course
in Massage Therapy and I also need to get some work to pay for all of
this.  Also, being realistic, I'm probably not going to be the one to
deliver the kind of app that most people here are after.  So, that's
how things seem to me.

Jim

--=20
 Jim Peters                  (_)/=3D\~/_(_)                 jim@...
                          (_)  /=3D\  ~/_  (_)
 Uaz=FA                  (_)    /=3D\    ~/_    (_)                http:/=
/
 Brighton, UK       (_) ____ /=3D\ ____ ~/_ ____ (_)            uazu.net

 OpenEEG -- EEG for the rest of us!   For details:  http://uazu.net/OE