Goals for software development

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 has yet to be 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 dragging-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 32 channels of data on a MacBook Air and >512 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 can go a long way. While the outward appearance of software is not always reflective of how stable things are under the hood, in our experience, it usually is.