-
Notifications
You must be signed in to change notification settings - Fork 0
Goals
The Open Ephys project began in 2011, when our labs were looking to replace our outdated tetrode recording rigs with the latest and greatest hardware. We compared offerings from a variety of vendors, including Neuralynx, Plexon, Triangle Biosystems, Alpha Omega, [Blackrock] (http://www.blackrockmicro.com/), Ripple, and Tucker-Davis Technologies. Unfortunately, none of these systems offered anywhere near the degree of flexibility we were hoping for.
Our interest in understanding neural circuits has inevitably led to our interest in perturbing neural circuits on the same timescales at which they operate. With the advent of optogenetic techniques, it's now possible to manipulate brain regions with an unprecedented degree of specificity. But, from our perspective, commercial hardware and software for controlling stimuli were far less sophisticated than the freely available molecular tools for controlling neurons. Even simple things, such as triggering a stimulus during periods of high spike activity, were tricky to accomplish using any of the available platforms.
On one end of the spectrum, there were systems (such as Neuralynx) that would allow us to stream data to other applications to be processed by custom code. This introduces a large time lag into the processing loop, making real-time feedback next to impossible. On the other end of the spectrum lie systems (such as those from Tucker-Davis Technologies) which integrate programmable digital signal processing into the hardware. However, these systems were not optimized for tetrode recordings, and included a graphical programming interface that looked incredibly difficult to configure. At the root of these problems was the fact that these systems are all closed. While we're perfectly happy buying closed-source software and hardware to avoid unnecessary hassles, it seemed unreasonable to spend hundreds of thousands of dollars on systems that couldn't do half of what we had hoped. Everything in science involves a tradeoff between doing it fast and doing it right. Because we knew we'd be stuck with whatever system we chose for at least the next ten years, we opted to take a few years and attempt to do it right.
Once we started down the path of building our own electrophysiology system from scratch, we didn't think twice before making it completely open source. We felt it was in our best interest to share anything we built with the community at large. We consider ourselves experts at using electrophysiology equipment, but not experts in building it. Therefore, we welcome input from anyone who has more expertise in this area than we do.
Another turning point was our discovery of Intan amplifier chips, which encapsulate the functionality of large, rack-mounted neural data processors in a tiny 8x8 mm surface-mount package. These will allow us to digitize our data on the headstage, improving signal fidelity and eliminating the need for bulky and expensive amplifier arrays. Commercial vendors such as Tucker-Davis Technologies already offer systems that incorporate these chips, so their reliability has been vetted by those who make a living off of electrophysiology systems. We expect to see many more such systems in the near future. Reid Harrison, the founder of Intan, has been extremely helpful in providing documentation and source code for working with his chips.
The Open Ephys project now includes members from the Wilson Lab at MIT, the Moore Lab at Brown, and the Kemere Lab at Rice. We'd love to have contributors from other labs, so if our motivations resonate with you, please get in touch!
Before designing the GUI, we set the following goals for ourselves (in rough order of priority):
-
The software should be flexible. Because technology is advancing so quickly, and experimental goals are often updated on a daily basis, we didn't want the software to make any assumptions about what hardware was providing the input, how the input should be processed, or what form the output would take. If this sounds like a lofty goal, take a look at any of the standard digital audio workstations. They receive inputs from many different sources (made by a variety of vendors), process them with a multitude of plug-ins (often coded by third-parties), and send their output to a wide array of digital and analog devices, literally without missing a beat. All commercial software for neuroscience does the opposite—you can only hook it up to hardware from the same vendor. Digital audio workstations also accomplish something else that hasn't been seen in neuroscience: they allow the user to configure processing pipelines on the fly. Inserting a new input, output, or filter is as easy as draging-and-dropping. Current neuroscience software, if it can be configured for new hardware at all, often requires editing a text file before the program is launched. In contrast, we wanted the core of the GUI to be agnostic to the nature of its inputs and outputs, which can be reconfigured at runtime in a logical manner.
-
The software should be open source. Unlike commercial systems, we wanted all aspects of our GUI to be transparent. This shouldn't mean that you have to understand every line of code to get it to work, but if you want to tweak something, it should be possible. So far, all the code used in this project, all the way down to the operating system if you're using Linux, is open-source. All of the libraries are GPL or LGPL-licensed, and the GUI itself is covered by the GPL license. That means you can hack it and share it as much as you like, but any products that are based on the source code must themselves be open.
-
The software should be easy to use. We don't want to force the user to learn an arcane set of configuration commands before they can acquire any data. While it's not unreasonable to spend a good amount of time familiarizing yourself with software you use on a daily basis, it's also not unreasonable to minimize user frustration by making software that works as intuitively as possible. We all make mistakes, and forgetting to write down a particular setting should not cause a dataset to be unusable; the software should keep track of everything so the user doesn't have to.
-
The software should be both portable and scalable. We want something that can acquire 16 channels of data on a MacBook or 256 channels on a beefed-up Linux workstation.
-
The software should look good. Function will always come before form, but a little attention to visual detail never killed anyone. While the outward appearance of software is not always reflective of how stable things are under the hood, in our experience, it usually is.
Maybe it's too early to think about the long-term goals, but that's also what inspires us to trade precious time running experiments for time developing software. If the Open Ephys project (or something like it) catches on, it could fundamentally change the way neuroscience is done.
As a community, we're currently investing countless millions of dollars into closed-source hardware and software that doesn't even work that well. If a tiny fraction of that money went toward developing and maintaining open-source tools, we could quickly develop platforms that surpass anything that's commercially available in terms of cost, flexibility, and usability. If one graduate student volunteering part-time for 6 months can produce the GUI in its current instantiation, imagine what a team of trained programmers could accomplish in a few years. The rise of the internet has made long-distance collaboration trivial, and the multitude of inexpensive rapid prototyping techniques make a large-scale, open-source platform a reasonable goal.
We're developing the GUI because we want to use it right away, but we also see it as a proof-of-concept. If we can show other neuroscientists how easy it is to build their own tools, perhaps it will inspire them to break free of their reliance on commercial hardware and software. We'll reiterate again: we have no problem using closed-source products when they work well, but the current state of tools available for extracellular electrophysiology is woefully inadequate. If others feel the same way, we can and should attempt to create something better on our own.
Continue to Program structure >>