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
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
>(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'.
> > 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.