-
Notifications
You must be signed in to change notification settings - Fork 0
TODO list
These are the things we hope to accomplish before the GUI is ready for an official release:
-
Allow individual processors to save their settings. Currently, the signal chain is saved whenever the program is closed, but the settings of each processor are not. The user needs to be able to load the exact same parameters each time the program is opened, so each processor will need to be able to write its settings to an XML file. In addition, the mechanism of loading and saving signal chains needs to be made more general, so the user can load and save configurations at any time, rather than just when the program is launched or closed.
-
Write custom filter code, or find a better filter library. Filtering many channels in parallel is hogging too many CPU cycles, especially if each channel needs to be filtered multiple times (e.g. once for spikes and once for LFP). This isn't too much of an issue on the most recent multicore processors, but we still want the bandpass filtering operations to be as efficient as possible, since they are used so often. (See the filterDirect branch for a rudimentary implementation).
-
Make the RecordNode more robust. By default, data at each stage of processing is sent to the RecordNode, which can then be saved in a simple binary format. We need to choose a more usable Data format (or allow the user to choose between several formats).
The minor revisions involve the creation of new sources, sinks, and visualizers to make the GUI more versatile.
-
Network nodes that make it possible to receive a UDP input stream or send packets of data to a particular address.
-
A tracking node which takes x/y coordinates as input.
-
Event-detection nodes for ripples and spindles.
-
A triggered-average node which aligns spikes to a specific event to create a histogram.
-
Frequency nodes, which display power in different frequency bands over time.
See the issues section of this site.
If the GUI becomes more popular, these changes would make it even more user-friendly and flexible:
-
Change the application to a plugin/host structure. Users would have a library of processors that can be dropped into the signal chain, but these processors could be written and compiled separately from the main application. This would make it simple for different labs to develop their own unique inputs, filters, and visualizers, which could be shared in a central repository. There are several options for how this could be implemented. One is to use an existing audio plugin format, such as VST or LV2. This should be straightforward, given Juce's rich set of classes for working with audio plugins, but would probably be overly restrictive. Another option is to use dynamically loaded objects in a shared library file (".so" on Unix, ".dll" on Windows), with the help of a runtime linking library, such as DynObj. This would offer greater flexibility, but it appears that DynObj only comes in a 32-bit version. To achieve true cross-platform compatibility, we'd either have to upgrade the library ourselves or find an alternative.
-
Create wrappers for Python and/or Matlab that allow processor code to be written in a higher-level language. This would encourage more people to contribute to the project, as it won't be essential to learn C++.
-
A suite of offline analysis tools would be a dream come true, but that's a huge project unto itself.
<< Back to How to contribute | Continue to Juce C++ library >>