The Google Summer of Code program provides a stipend for university students who want to spend a summer contributing code to open-source projects. Open Ephys is applying as a mentoring organization in 2016. We'll know by February 29th whether or not we've been accepted.
Below is a list of projects that would be extremely beneficial to our user base, and which could be completed in a 12-week period.
...
If you're new to Open Ephys, we recommend reading through our main website, this wiki, and our google group, or just email info@open-ephys.org and let us know what projects you might be interested in working on. You should also read through the GSoC Student Manual if download our software and work your way through this Tutorial.
If you haven't already, you should read through the GSoC Student Manual. The 2016 student application window is March 14th through 25th.
Application instructions
You'll officially apply through Google starting March 14th. The information on this page is intended to help you decide if you'd like to develop a proposal with us.
Open Ephys is looking for students to help us improve our GUI (http://www.open-ephys.org/gui/), an open-source data acquisition application used by neuroscientists across the globe. You'll have the opportunity to contribute code that will be applied immediately to real experiments in neuroscience labs across the world, as well as to learn the scientific motivations that drove us to create Open Ephys.
The only prerequisite is proficiency in C++, as demonstrated through coursework, code samples, and discussions with potential mentors. Experience with signal processing, data visualization, machine learning, embedded systems, and/or the Juce framework may be helpful, but are not necessary. Our software runs on Windows, Mac, and Linux, so you'll be able to work with the OS of your choice.
To applystart developing your proposal with Open Ephys, please send a resume, a the following information to info@open-ephys.org:
- Contact details: full name, location, email, and Skype account name
- An up-to-date resume
- A link to your GitHub page
...
- (with a list of the repositories you've contributed the most to)
- A 1-page letter describing the project(s) you're interested in working on to
...
- (see below for suggestions)
- Bonus points
...
- if you've already squashed some bugs listed at https://github.com/open-ephys/gui/issues
Proposal ideas
Below is a list of potential projects for GSoC students. This is just a subset of the many possibilities, so feel free to suggest your own ideas as well. This list will also be useful for anyone else that's looking for ways to contribute to the GUI.
1. Julia plugin modulePlugin generation GUI
Description: Creating custom processing modules for the The Open Ephys GUI currently requires knowledge of C++. However, most scientists prefer to write code in high-level languages, such as Python and Matlab. Julia is a relatively new language for scientific computing that combines a syntax similar to Matlab with the speed of compiled C++. It's easy to call Julia code from a C++ application using the Julia C++ interface. In order to take advantage of the vast amount of signal processing code that's been written by neuroscientists, and to make it easier for users to modify the GUI, we'd like to make it possible to run Julia code directly within our software. Julia modules could be used for such applications as detecting patterns in spiking activity or performing spectral analysis on neural signals. We already have a working minimal prototype (https://github.com/open-ephys/gui/tree/jvoigts), but it needs to be made more robust and user-friendlyis based on a host–plugin architecture, in which processing modules are compiled separately from the main application and can be loaded on the fly. This makes it easier for users to add new functionality: they only need to understand the interface for piping data in and out of a processor, rather than the inner workings of the entire application. Nevertheless, there are still a number of mundane steps that must be carried out before one can start writing code for processing data. We'd like to have these steps be done automatically, guided by a graphical interface. The user would type in a name for their processor, and select some basic attributes, and the software would generate all the necessary files and some boilerplate code. The interface could either be standalone, or integrated into the main GUI. This would help lower the barrier for entry for scientists interested in upgrading the GUI's functionality.
Skills required: Proficiency in C++, experience designing user interfaces
Level of difficulty: Easy
Potential mentor: Josh Siegle (@jsiegle)
2. Upgrade channel selection interface
Description: Every processing module within the Open Ephys GUI includes a generic interface that allows the user to select subsets of channels for editing parameters and toggling recording on and off. Currently, users can only select or deselect one channel at a time, and the interface does not scale well to high channel counts. We're looking for someone to re-design the interface so that the buttons for each channel can be visualized more effectively and channel selection can be performed more efficiently.
Skills required: Proficiency with in C++, especially integrating it with other languagesMentorexperience designing user interfaces
Level of difficulty: Easy
Potential mentor: Jakob Voigts (@jvoigts)
23. Event-triggered averaging module
...
Skills required: Proficiency in C++, basic signal processing background
MentorLevel of difficulty: Moderate
Potential mentor: Josh Siegle (@jsiegle)
3. Plugin generation GUI4. Julia plugin module
Description: The Creating custom processing modules for the Open Ephys GUI is based on a host–plugin architecture, in which processing modules are compiled separately from the main application and can be loaded on the fly. This makes it easier for users to add new functionality: they only need to understand the interface for piping data in and out of a processor, rather than the inner workings of the entire application. Nevertheless, there are still a number of mundane steps that must be carried out before one can start writing code for processing data. We'd like to have these steps be done automatically, guided by a graphical interface. The user would type in a name for their processor, and select some basic attributes, and the software would generate all the necessary files and some boilerplate code. The interface could either be standalone, or integrated into the main GUI. This would help lower the barrier for entry for scientists interested in upgrading the GUI's functionalitycurrently requires knowledge of C++. However, most scientists prefer to write code in high-level languages, such as Python and Matlab. Julia is a relatively new language for scientific computing that combines a syntax similar to Matlab with the speed of compiled C++. It's easy to call Julia code from a C++ application using the Julia C++ interface. In order to take advantage of the vast amount of signal processing code that's been written by neuroscientists, and to make it easier for users to modify the GUI, we'd like to make it possible to run Julia code directly within our software. Julia modules could be used for such applications as detecting patterns in spiking activity or performing spectral analysis on neural signals. We already have a working minimal prototype (https://github.com/open-ephys/gui/tree/jvoigts), but it needs to be made more robust and user-friendly.
Skills required: Proficiency in with C++, experience designing user interfacesMentor: Josh Siegle (@jsiegleespecially integrating it with other languages
Level of difficulty: Moderate
Potential mentor: Jakob Voigts (@jvoigts)
45. Behavior scoring with accelerometer data
...
Skills required: Proficiency in C++, knowledge of basic machine learning algorithms (to be implemented in Python, Julia, or C++)Mentor
Level of difficulty: Difficult
Potential mentor: Jakob Voigts (@jvoigts)
56. OpenBCI integration
Description: The majority of Open Ephys users are academic researchers performing experiments on animal models. However, the flexibility of the Open Ephys GUI would make it ideal for working with data from humans as well. Although the Open Ephys acquisition board can be adapted for use with human EEG, there are better alternatives out there. OpenBCI is a widely used open-source platform for streaming EEG data to a computer. Enabling the Open Ephys GUI to interface with OpenBCI hardware would allow our software to reach a much wider audience. We'd like to create a source module that could receive data from a 16-channel OpenBCI board. Next, existing visualization modules (such as the LFP Viewer) should be optimized for use with EEG data. In addition, modules for spectral analysis and machine learning could be created to respond to changes in brain state in real time.
Skills required: Proficiency in C++, familiarity with microcontrollers and USB serial communication
MentorLevel of difficulty: Difficult
Potential mentor: Josh Siegle (@jsiegle)
...