Loading ...
Sorry, an error occurred while loading the content.

Question for Doug

Expand Messages
  • John Morrison
    Just a quick question. When the system is complete and someone produces a new class/object you want to try is it possible for the system to add instantiate
    Message 1 of 10 , Feb 27 7:07 PM
    • 0 Attachment
      Just a quick question.
      When the system is complete and someone produces a new class/object you want
      to try is it possible for the system to add "instantiate" it with out
      recompiling the program?

      Thanks

      John Morrison MailTo:jmorrison@...
      ICQ - 367473
    • Doug Sutherland
      ... Compilation and instantiation are different things. In Java, you compile your code into bytecode, those .class files. There will always be one main method,
      Message 2 of 10 , Feb 27 8:43 PM
      • 0 Attachment
        John Morrison wrote:

        > When the system is complete and someone produces a new
        > class/object you want to try is it possible for the system
        > to add "instantiate" it with out recompiling the program?

        Compilation and instantiation are different things. In Java,
        you compile your code into bytecode, those .class files.
        There will always be one main method, this instantiates
        objects which in turn instantiate other objects. The class
        file is like a "blueprint" of an object, it doesn't live
        until it's instantiated, and many of it can be instantiated.

        The code must be compiled before it can be used (obviously).
        The same holds true for C++ but rather than bytecode we are
        creating binary object modules. You really need to get away
        from speaking of "the program" when dealing with OO, there
        is no one program, it's a bunch of classes. For OpenEEG we
        will have a main program that will launch everything else,
        but it should be very small and simple.

        -- Doug
      • John Morrison
        ... Yep know all that as far as Java is concerned. Which is one of the reasons that I originally was advocating Java. ... BUT with C++ (at least the contact
        Message 3 of 10 , Feb 27 9:26 PM
        • 0 Attachment
          > > When the system is complete and someone produces a new
          > > class/object you want to try is it possible for the system
          > > to add "instantiate" it with out recompiling the program?
          >
          > Compilation and instantiation are different things. In Java,
          > you compile your code into bytecode, those .class files.
          > There will always be one main method, this instantiates
          > objects which in turn instantiate other objects. The class
          > file is like a "blueprint" of an object, it doesn't live
          > until it's instantiated, and many of it can be instantiated.
          Yep know all that as far as Java is concerned.
          Which is one of the reasons that I originally was advocating Java.

          > The code must be compiled before it can be used (obviously).
          > The same holds true for C++ but rather than bytecode we are
          > creating binary object modules. You really need to get away
          BUT with C++ (at least the contact I've had with it) the end product is one
          .EXE file.
          So if someone sends you an Object module do we need to recompile to a new
          .EXE
          or is there a way for the "MAIN" to instantiate it from the Object module?
          EG If someone produces a new filter module and sends the Object module to
          you?

          > from speaking of "the program" when dealing with OO, there
          When we create the classes it'll be better as I can speak of this or that
          class then. :-)

          > is no one program, it's a bunch of classes. For OpenEEG we
          > will have a main program that will launch everything else,
          > but it should be very small and simple.
          That is exactly what I was thinking!

          >
          > -- Doug

          John
        • Doug Sutherland
          John, There is a good brief intro on the difference between functional orientation and object orientation here:
          Message 4 of 10 , Feb 27 10:14 PM
          • 0 Attachment
            John,

            There is a good brief intro on the difference between functional
            orientation and object orientation here:

            http://www.cranfield.ac.uk/sims/quality/quality2/cpd_courses/cpp_intro.html

            I am obviously a proponent of object orientation. We spoke about
            RMI earlier, what got me hooked on RMI is the fact that it is a
            truly object oriented distributed system, the only one that I am
            aware of. What this means is that it preseres polymorphism even
            across machine/memory boundaries. I can create a heierarchy that
            represents an object (supertype and subtypes) and pass that as
            an argument is a remote method call. If the calling process is
            local, it will "pass by reference" (ie pointer), but if it's
            remote, it will "pass by value", it will serialize that object
            in its entirety and reconstruct it on the other side.

            Take the classic OO example of polymorphism: shapes. I create
            a generic shape super type. I then create sub-types for circle,
            square, and triangle. All shapes have methods that are in
            common, as represented in the supertype. I can pass any shape
            around anyhwhere and it will have a shape.draw() method. The
            code that operates on shapes intetionally does not know about
            the uniqueness of the subclass (unless it has to). The shape
            ITSELF takes care of its drawing, not the code around it. In
            the old world we would do

            if circle then
            blah
            else if square then
            blah
            else if triangle then
            blah

            And we would do that in many places. In OO we don't do that,
            we specifically avoid that, instead we operate on the notion
            of polymorphism, we say shape.draw() or shape.getArea() etc,
            we never reference a circle or square or triangle. Later
            when we add new subtypes (polygon), NONE of the code has to
            change, the polygon ITSELF knows what to do (everything that
            is specific about polygons), and the super type is what all
            or at least most of the code operates on. The cool thing
            about RMI is it can preserve this polymorphism across the
            wire. The bad thing about RMI is that there is a lot of
            overhead in doing this. The passing of a raw stream of data
            like EEG data is a perfect example where RMI is the wrong
            tool for the job, probably IP sockets would work.

            Apply these concepts of inheritance, encapsulation, and
            polymorphism to EEG. Think entities and relationships first.
            We have sensors, filters, displays, users, configurations,
            etc. Most of these can and will exists in heirarchies of
            supertypes and sub-types. If we think carefully on this we
            can come up with just a dozen or so objects. Then we work
            on methods, for both the super and sub types. From there
            we examine the relationships and figure out how to apply
            design patterns like MVC for event handling. My proposal
            then is not to think about EEG data and EEG functions,
            instead we should be thinking about sensor entities and
            entities that relate to sensors. We could break this down
            functionally, and componentization would probably do that,
            but I'm a proponent of OO, an if we don't do OO then I
            will do it anyways.

            Now, let's go back to your question, you said that when
            you compile C++ you get an .EXE (executable). All native
            code compilation involves two steps, creation of an
            object module, then linking to a loadable or executable.
            When you compile a C program, it creates .o files first
            (object modules) and the final link creates the end
            result, often an single executable as you say. But there
            are different kinds of linking: static and and dynamic.

            Static linking goes out into the libraries referenced
            and copies the code into the executable. Dynamic linking
            does NOT copy the code, it refers a shared library. A
            statically linked program is self-contained, it needs
            nothing else, and chews a lot of ram in the process.
            A dynamically linked program will resolve the symbol
            table at RUNTIME and load the necessary code ON DEMAND
            from shared libraries. So we DON'T end up with one big
            honking huge memory hog executable, we create a small
            main program, we create shared libraries, and the C++
            program loads only what it needs on the fly. The only
            COST is disk space, and this won't be a huge system.

            -- Doug
          • John Morrison
            DOUG, I KNOW OO !!!!!!!!!! I ve just spent 3 years at University an almost everything taught is OO. ... But I do like your explanation! ... OO All the way! ...
            Message 5 of 10 , Feb 28 2:54 AM
            • 0 Attachment
              DOUG,

              I KNOW OO !!!!!!!!!!
              I've just spent 3 years at University an almost everything taught is OO.
              :-)
              But I do like your explanation!

              > Apply these concepts of inheritance, encapsulation, and
              > polymorphism to EEG. Think entities and relationships first.
              > We have sensors, filters, displays, users, configurations,
              > etc. Most of these can and will exists in heirarchies of
              > supertypes and sub-types. If we think carefully on this we
              > can come up with just a dozen or so objects. Then we work
              > on methods, for both the super and sub types. From there
              > we examine the relationships and figure out how to apply
              > design patterns like MVC for event handling. My proposal
              > then is not to think about EEG data and EEG functions,
              > instead we should be thinking about sensor entities and
              > entities that relate to sensors. We could break this down
              > functionally, and componentization would probably do that,
              > but I'm a proponent of OO, an if we don't do OO then I
              > will do it anyways.
              OO All the way!


              > Now, let's go back to your question, you said that when
              > you compile C++ you get an .EXE (executable). All native
              > code compilation involves two steps, creation of an
              > object module, then linking to a loadable or executable.
              > When you compile a C program, it creates .o files first
              > (object modules) and the final link creates the end
              > result, often an single executable as you say. But there
              > are different kinds of linking: static and and dynamic.
              >
              > Static linking goes out into the libraries referenced
              > and copies the code into the executable. Dynamic linking
              > does NOT copy the code, it refers a shared library. A
              > statically linked program is self-contained, it needs
              > nothing else, and chews a lot of ram in the process.
              > A dynamically linked program will resolve the symbol
              > table at RUNTIME and load the necessary code ON DEMAND
              > from shared libraries. So we DON'T end up with one big
              > honking huge memory hog executable, we create a small
              > main program, we create shared libraries, and the C++
              > program loads only what it needs on the fly. The only
              > COST is disk space, and this won't be a huge system.
              I'm not sure how this allows us to add new classes/objects, but don't care
              right now lets get this show on the road!

              > -- Doug

              John
            • Doug Sutherland
              John, ... The point of that dissertation was to attempt to move this design/planning discussion towards entities and relationships, objects, classes and
              Message 6 of 10 , Feb 28 2:01 PM
              • 0 Attachment
                John,

                > I KNOW OO ... I've just spent 3 years at University
                > an almost everything taught is OO.

                The point of that dissertation was to attempt to move
                this design/planning discussion towards entities and
                relationships, objects, classes and interfaces, object
                methods that make up APIs, and design patterns that
                flesh out relationships via event handling. The nature
                of OO is not really modular like components, it is
                more abstract, and for good reasons.

                > I'm not sure how this allows us to add new classes/
                > objects, but don't care right now lets get this show
                > on the road!

                I'm not sure where the confusion is. If you modify
                an existing class, extend an existing class, or add
                new classes or interfaces, you run a make file, the
                build script detects what has been changed, and
                updates shared libraries. This is not much different
                from Java, where class files get updated. If a new
                class file is in the classpath (Java) it is found
                and used; if a new (revised) library is in the load
                library path (C/C++), it gets used.

                I would imagine that like all software, we will have
                a development tree and a stable release tree, will
                go through major and minor releases, and have the
                precompiled binaries that work on the various target
                deployment platforms, probably including

                - Win9x, WinNT, Win2K
                - Linux 2.2.x and 2.4.x kernels

                > hunting around for UML programs

                Although UML is useful, there is danger in jumping
                into automated tools. We have a small number of
                objects and relationships here. We should be able
                to sort that out the old fashined no tech way.

                -- Doug
              • John Morrison
                ... OK here is a start on the design can I have a few words on it or should I give up sit back and stop wasting my time?? ... They are just off the top of my
                Message 7 of 10 , Mar 1, 2002
                • 0 Attachment
                  > I would imagine that like all software, we will have
                  > a development tree and a stable release tree, will
                  > go through major and minor releases, and have the
                  > precompiled binaries that work on the various target
                  > deployment platforms, probably including
                  >
                  > - Win9x, WinNT, Win2K
                  > - Linux 2.2.x and 2.4.x kernels
                  >
                  > > hunting around for UML programs
                  >
                  > Although UML is useful, there is danger in jumping
                  > into automated tools. We have a small number of
                  > objects and relationships here. We should be able
                  > to sort that out the old fashined no tech way.

                  OK here is a start on the design can I have a few words on it or should I
                  give up sit back and stop wasting my time??

                  ----------------------------------------------------------------------------
                  -----------------

                  They are just off the top of my head so please add/remove/correct them as
                  you see fit.
                  They are just suggestions for possible classes not all of which will ever
                  be written!


                  - Methods start with a : all others are classes.
                  - Indenting shows sub classes

                  Hardware(Class)
                  :initialise - initialise the object but don't start sampling yet
                  :start - Start Sampling
                  :reset - Reset object (maybe just a call to initialise)
                  :stop - Stop sampling
                  :setSamplingRate - Set sampling rate :-) Thanks Doug
                  :getSerialData - a "protected" method used to access serial port data
                  - there would be a whole range of "protected" Serial interface methods
                  - Of course the library for Linux and Windows would be different
                  - This way authors can write code for a piece of hardware without
                  concern for the operating system

                  EEG(Class)
                  OPENEEG(CLASS) - Our baby :-)

                  ECG(Class)

                  EMG(Class)

                  GSR(Class)

                  File(Class)
                  :SetFileName - Set file name to read

                  Processing(Class)
                  :initialise - initialise the object
                  :reset - Reset object (maybe just a call to initialise)

                  Filter(Class) - any sort of filter

                  Trigger(Class) - Classes that provide an output (Digital) when trigger
                  conditions are met

                  UserInterface(Class)
                  :initialise - initialise the object
                  :reset - Reset object (maybe just a call to initialise)

                  VDU(Class) - All objects that display to the screen

                  File(Class) - Saving data to a file.
                  :SetFileName - Set file name to write

                  biAudio(Class) - Produce BI-Audio beat frequency signals

                  goggles(Class) - LED glasses for brain stimulation

                  playerMP3 - Play MP3 files (eg relaxation music, hypnosis, etc)

                  ----------------------------------------------------------------------------
                  -----------------

                  John
                • Doug Sutherland
                  John, ... This looks pretty decent actually. We need to talk to the hardware guys and figure out exactly what is configurable in the microcontroller. ... Here
                  Message 8 of 10 , Mar 1, 2002
                  • 0 Attachment
                    John,

                    > Hardware(Class)
                    > :initialise - initialise the object but don't start sampling yet
                    > :start - Start Sampling
                    > :reset - Reset object (maybe just a call to initialise)
                    > :stop - Stop sampling
                    > :setSamplingRate - Set sampling rate

                    This looks pretty decent actually. We need to talk
                    to the hardware guys and figure out exactly what
                    is configurable in the microcontroller.


                    > EEG(Class) OPENEEG(CLASS) - Our baby :-)
                    > ECG(Class)
                    > EMG(Class) <-- these are our babies too
                    > GSR(Class)

                    Here is where things will change if we do object oriented.
                    All of the above are sensors, so we have a sensor class

                    Sensor (Class)
                    // all methods common to sensors go in super type, then
                    EEG (Class) extends Sensor
                    ECG (Class) extends Sensor
                    EMG (Class) extends Sensor
                    GSR (Class) extends Sensor

                    Each of these sub-types can override methods in the
                    super type (Sensor) if they need to, and they might
                    add extra methods specific to their type.

                    > getSerialData
                    > - a "protected" method used to access serial port data
                    > - there would be a whole range of "protected" Serial
                    > interface methods
                    > - Of course the library for Linux and Windows would be
                    > different
                    > - This way authors can write code for a piece of hardware
                    > without concern for the operating system

                    This needs to change a bit I think. This really needs to
                    be a listener, not a method that you invoke on a sensor.
                    Once you call EEG.start then data will be coming at us in
                    a stream. We have a six channel device in the works, some
                    may be EEG and some ECG or whatever, all will arrive in
                    the same serial stream. So we don't call a sensor to get
                    the data, it continually streams in on the serial port.
                    There we have a class that wraps the native serial code.
                    It will also have to determine which data is for which
                    hardware. There might be two options:

                    1) Some kind of configuration object specifies which
                    channel is for which devices.

                    2) Some protocol info in the serial stream determines
                    the type of data.

                    Here is where your framework idea comes in. The
                    listener needs to call something else to filter
                    the data, and eentually we want to render it. We
                    need to separate these things. This is where I
                    think something like MVC design pattern makes
                    sense (or some other design pattern).

                    > File(Class)
                    > :SetFileName - Set file name to read

                    We will have several different types of files.
                    Some will be log files, writing the samples to
                    disk. Others will be user configuration info.
                    We want the system to allow a user to save his
                    own setup and persist his settings, log his
                    data in a separate place. Maybe we have a
                    logging class and a configuration class.

                    > Processing(Class)
                    > :initialise - initialise the object
                    > :reset - Reset object (maybe just a call to initialise)

                    Processing is a bit too generic I think. Skip that.

                    > Filter(Class) - any sort of filter

                    Perhaps we can have filter supertype and several
                    sub-types. We need to understand the flow of the
                    data and events in terms of that framework idea
                    to figure this out.

                    > Trigger(Class) - Classes that provide an output
                    > (Digital) when trigger conditions are met

                    We also need to add some support for neurofeedback
                    training protocols in here, and triggers are part
                    of that. For example, when a user gets into the
                    target range they need to be notified. This is
                    another reason for abstraction: it may be GUI
                    or audio or some other method.

                    > UserInterface(Class)

                    We will probably have more than one class that makes up the
                    user interface. One type of class would probably be the data
                    displays (waveforms or bar charts or pie charts plus numerical).
                    Each represent the same data in different ways, so it makes
                    sense to have a super and subtypes. Others will associate
                    with configuration, others may control the overall program.

                    Back to the idea of Jim wanting console interface and others
                    wanting GUI ... in this paper on MVC design pattern, it says ...

                    Not all people can or prefer to operate a computer in the
                    same way. Therefore: Separate the controls of the computer
                    from the views it presents so that appropriate controls
                    can be selected by the user. A handicapped individual
                    would be an example of a user needing a different kind of
                    control.

                    http://c2.com/cgi/wiki?ModelViewController
                    http://rd13doc.cern.ch/Atlas/Notes/004/Note004-7.html
                    http://www.enode.com/xalt/markup/tutorial/mvc.html

                    If we want to make a flexible system, we need this kind
                    of abstraction, not only between the the GUI and data
                    but also between the process (filtering) etc. I'm not
                    sure if MVC is quite right for that, but something
                    similar probably makes sense.

                    -- Doug
                  • John Morrison
                    Just thought of some other classes. UserInput(Class) Joystick(Class) - Like the circuit used by one of the L/S machines Keyboard(Class) - Voice(Class) - For
                    Message 9 of 10 , Mar 1, 2002
                    • 0 Attachment
                      Just thought of some other classes.

                      UserInput(Class)
                      Joystick(Class) - Like the circuit used by one of the L/S machines
                      Keyboard(Class) -
                      Voice(Class) - For Doug :-)
                      InfraRed(Class) -

                      Have I forgotten anything Doug? You've got a lot more real-word experience
                      than I have!!

                      John

                      > -----Original Message-----
                      > From: John Morrison [mailto:jmorrison@...]
                      > Sent: Friday, 1 March 2002 10:14 PM
                      > To: buildcheapeeg@yahoogroups.com
                      > Subject: RE: [buildcheapeeg] Question for Doug
                      >
                      >
                      > > I would imagine that like all software, we will have
                      > > a development tree and a stable release tree, will
                      > > go through major and minor releases, and have the
                      > > precompiled binaries that work on the various target
                      > > deployment platforms, probably including
                      > >
                      > > - Win9x, WinNT, Win2K
                      > > - Linux 2.2.x and 2.4.x kernels
                      > >
                      > > > hunting around for UML programs
                      > >
                      > > Although UML is useful, there is danger in jumping
                      > > into automated tools. We have a small number of
                      > > objects and relationships here. We should be able
                      > > to sort that out the old fashined no tech way.
                      >
                      > OK here is a start on the design can I have a few words on it or should I
                      > give up sit back and stop wasting my time??
                      >
                      > ------------------------------------------------------------------
                      > ----------
                      > -----------------
                      >
                      > They are just off the top of my head so please
                      > add/remove/correct them as
                      > you see fit.
                      > They are just suggestions for possible classes not all of
                      > which will ever
                      > be written!
                      >
                      >
                      > - Methods start with a : all others are classes.
                      > - Indenting shows sub classes
                      >
                      > Hardware(Class)
                      > :initialise - initialise the object but don't start sampling yet
                      > :start - Start Sampling
                      > :reset - Reset object (maybe just a call to initialise)
                      > :stop - Stop sampling
                      > :setSamplingRate - Set sampling rate :-) Thanks Doug
                      > :getSerialData - a "protected" method used to access
                      > serial port data
                      > - there would be a whole range of
                      > "protected" Serial interface methods
                      > - Of course the library for Linux
                      > and Windows would be different
                      > - This way authors can write code
                      > for a piece of hardware without
                      > concern for the operating system
                      >
                      > EEG(Class)
                      > OPENEEG(CLASS) - Our baby :-)
                      >
                      > ECG(Class)
                      >
                      > EMG(Class)
                      >
                      > GSR(Class)
                      >
                      > File(Class)
                      > :SetFileName - Set file name to read
                      >
                      > Processing(Class)
                      > :initialise - initialise the object
                      > :reset - Reset object (maybe just a call to initialise)
                      >
                      > Filter(Class) - any sort of filter
                      >
                      > Trigger(Class) - Classes that provide an output (Digital)
                      > when trigger
                      > conditions are met
                      >
                      > UserInterface(Class)
                      > :initialise - initialise the object
                      > :reset - Reset object (maybe just a call to initialise)
                      >
                      > VDU(Class) - All objects that display to the screen
                      >
                      > File(Class) - Saving data to a file.
                      > :SetFileName - Set file name to write
                      >
                      > biAudio(Class) - Produce BI-Audio beat frequency signals
                      >
                      > goggles(Class) - LED glasses for brain stimulation
                      >
                      > playerMP3 - Play MP3 files (eg relaxation music,
                      > hypnosis, etc)
                      >
                      > ------------------------------------------------------------------
                      > ----------
                      > -----------------
                      >
                      > John
                      >
                      >
                      >
                      > To unsubscribe from this group, send an email to:
                      > buildcheapeeg-unsubscribe@egroups.com
                      >
                      >
                      >
                      > Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
                      >
                      >
                      >
                    • John Morrison
                      ... This actually and internal SENSOR method in the super class so that the sensor subclasses don t have to worry about working with Linux serial code,
                      Message 10 of 10 , Mar 1, 2002
                      • 0 Attachment
                        > > getSerialData
                        > > - a "protected" method used to access serial port data
                        > > - there would be a whole range of "protected" Serial
                        > > interface methods
                        > > - Of course the library for Linux and Windows would be
                        > > different
                        > > - This way authors can write code for a piece of hardware
                        > > without concern for the operating system
                        >
                        > This needs to change a bit I think. This really needs to
                        > be a listener, not a method that you invoke on a sensor.
                        This actually and internal SENSOR method in the super class so that the
                        sensor subclasses don't' have to worry about working with Linux serial
                        code, Windows serial code, etc.

                        > Once you call EEG.start then data will be coming at us in
                        > a stream. We have a six channel device in the works, some
                        > may be EEG and some ECG or whatever, all will arrive in
                        > the same serial stream. So we don't call a sensor to get
                        > the data, it continually streams in on the serial port.
                        > There we have a class that wraps the native serial code.
                        > It will also have to determine which data is for which
                        > hardware. There might be two options:
                        >
                        > 1) Some kind of configuration object specifies which
                        > channel is for which devices.
                        >
                        > 2) Some protocol info in the serial stream determines
                        > the type of data.

                        What about option 3 (I'm assuming you are talking about data from sensor to
                        processing)

                        3) The sensor object gives us just the device data we request.
                        - Listeners is the way I was thinking too!
                        - A setup call (for the listener) will designate the channel/device.

                        OR are you talking device to sensor code ??

                        > Here is where your framework idea comes in. The
                        > listener needs to call something else to filter
                        > the data, and eentually we want to render it. We
                        > need to separate these things. This is where I
                        > think something like MVC design pattern makes
                        > sense (or some other design pattern).
                        >
                        > > File(Class)
                        > > :SetFileName - Set file name to read
                        >
                        > We will have several different types of files.
                        > Some will be log files, writing the samples to
                        > disk. Others will be user configuration info.
                        > We want the system to allow a user to save his
                        > own setup and persist his settings, log his
                        > data in a separate place. Maybe we have a
                        > logging class and a configuration class.
                        Make File a Super class so we can put generic filehandling functions there?

                        Configuration
                        - hmm we are going to look into this as various objects may have there own
                        configuration options?
                        - Maybe each object could register with the Config object and handle there
                        own sections......
                        - Something to think about



                        > > Processing(Class)
                        > > :initialise - initialise the object
                        > > :reset - Reset object (maybe just a call to initialise)
                        >
                        > Processing is a bit too generic I think. Skip that.
                        >
                        > > Filter(Class) - any sort of filter
                        >
                        > Perhaps we can have filter supertype and several
                        > sub-types. We need to understand the flow of the
                        > data and events in terms of that framework idea
                        > to figure this out.
                        >
                        > > Trigger(Class) - Classes that provide an output
                        > > (Digital) when trigger conditions are met
                        >
                        > We also need to add some support for neurofeedback
                        > training protocols in here, and triggers are part
                        > of that. For example, when a user gets into the
                        > target range they need to be notified. This is
                        > another reason for abstraction: it may be GUI
                        > or audio or some other method.
                        That is the idea behind Trigger!
                        We have various trigger classes to use.
                        When a trigger object hits the trigger condition it notifies a "User
                        Interface" object that gives the appropriate feedback!

                        > > UserInterface(Class)
                        >
                        > We will probably have more than one class that makes up the
                        > user interface. One type of class would probably be the data
                        > displays (waveforms or bar charts or pie charts plus numerical).
                        > Each represent the same data in different ways, so it makes
                        > sense to have a super and subtypes. Others will associate
                        > with configuration, others may control the overall program.
                        I agree I think "User Interface" should be the last one we look at.
                        There are a LOT of traps in the user side!!!


                        > Back to the idea of Jim wanting console interface and others
                        > wanting GUI ... in this paper on MVC design pattern, it says ...
                        >
                        > Not all people can or prefer to operate a computer in the
                        > same way. Therefore: Separate the controls of the computer
                        > from the views it presents so that appropriate controls
                        > can be selected by the user. A handicapped individual
                        > would be an example of a user needing a different kind of
                        > control.
                        >
                        > http://c2.com/cgi/wiki?ModelViewController
                        > http://rd13doc.cern.ch/Atlas/Notes/004/Note004-7.html
                        > http://www.enode.com/xalt/markup/tutorial/mvc.html
                        >
                        > If we want to make a flexible system, we need this kind
                        > of abstraction, not only between the the GUI and data
                        > but also between the process (filtering) etc. I'm not
                        > sure if MVC is quite right for that, but something
                        > similar probably makes sense.
                        hmm needs some thought........
                        Thanks for the MVC links I needed a refresh on them. :-)


                        > -- Doug


                        Ok seeing as one Hardware device could have various sensors connected to it
                        we could break it down like this

                        Device(super-class)
                        :initialise - initialise the object but don't start reading yet
                        :start - Start Sampling
                        :reset - Reset object (maybe just a call to initialise)
                        :stop - Stop sampling
                        :getSerialData - internal method for subclasses
                        OpenEEG(class)
                        File(Class) - Replays recorded data

                        Sensor(super-class)
                        :setSamplingRate - Set sampling rate :-) Thanks Doug
                        EEG(Class)
                        ECG(Class)
                        EMG(Class)
                        GSR(Class)

                        Then we connect a sensor object (eg EEG) to a channel on a device (eg
                        OPENEEG). EEG being a listener!
                        Chan
                        OPENEEG --01--> EEG
                        \--02--> ECG

                        It's midnight here so time for bed!
                        C U all later
                        John
                      Your message has been successfully submitted and would be delivered to recipients shortly.