Re: [buildcheapeeg] Software architecture

From: Jim Peters (jim_at_uazu.net)
Date: 2002-02-15 10:15:59


John Morrison wrote:
> I'll have to think on this one.
> I've been thinking REAL-TIME/recorded system but I never thought of back
> tracking???
> For the modular system I've described in the requirement spec I sent on the
> 13/02 your system could be bracken down as such.
> File Module reads file, sends data to analysis module which collects it and
> sends results to display module, Display modules controls File module by
> telling it what to send next.

'Back-tracking' is hard for some types of DSP algorithms to handle,
but easy for others. For instance, an IIR filter builds up a kind of
memory of recent history in its buffers -- you can't just 'rewind the
tape' and expect it to work straight off.

I think the best thing is for you to approach my analysis app as a
kind of prototype. Once I have it working, and you've had a play with
it, maybe you can see how it could be made to fit into your ideas. If
it doesn't fit, maybe we could make 'analysis' and 'biofeedback' two
different parts of the program ?

> > http://www.arts-project.org/
> > http://kde.org/
> Looks great BUT it's LINUX/KDE based and not portable at all. :-(

The aRts layer is portable, but the graphical front-end is obviously
KDE-specific. (Actually, as it is Qt based, perhaps it is portable to
Qt/Windows -- I don't know)

"aRts" was originally an independent project before KDE adopted it as
their sound layer.

> LADSPA sounds interesting and seems to be following the same lines as to
> what I'd like our program to do.
> I'll have a better read latter.......:-)
> After all EEG signals are VERY much like audio signals. :-)

LADSPA is a plugin standard (like VST). You need to look at some of
the open-source apps that support LADSPA (like 'ecasound'). They are
the ones that have the infrastructure and scheduling code already
built and tested. If it's open-source and under a friendly licence,
you can take what you need and adapt it as necessary.

Just one difference between audio and EEG, and that is that in
processing audio, you often work with blocks of 64 or 256 samples at a
time. With EEG, the sample rate is much lower, and you'd need much
smaller blocks, or even no blocks at all (i.e. processing 1 sample at
a time). Probably it is straightforward to configure existing code to
work with smaller block sizes.

I hope you don't mind, but I plan to work assuming no modular system
for now. However if you and others can do some research and find a
good existing modular system that can be adapted and made to work
well, then I'll certainly contribute DSP modules for it.

Also, if you have a look at what has already been done, you'll have an
idea of the issues involved, and of the amount of work required if you
decided to redesign and code it all from scratch.

At the moment, I'm just working with a "shortest path to where I want
to go" kind of approach, and I don't personally need a modular plugin
system yet, so I'll be putting my time into looking at DSP and things
like that for now.

Jim

-- 
Jim Peters (_)/=\~/_(_) jim_at_uazu.net
(_) /=\ ~/_ (_)
Uazú (_) /=\ ~/_ (_) http://
B'ham, UK (_) ____ /=\ ____ ~/_ ____ (_) uazu.net


This archive was generated by hypermail 2.1.4 : 2002-07-27 12:28:38 BST