open-ephys / plugin-gui

Software for processing, recording, and visualizing multichannel electrophysiology data

Open Ephys GUI

The Open Ephys GUI is designed to provide a fast and flexible interface for acquiring and visualizing data from extracellular electrodes. Compatible data acquisition hardware includes:

• Open Ephys Acquisition Board (supports up to 512 channels)
• Intan RHD USB Interface Board (supports up to 256 channels)
• Intan Recording Controller (supports up to 1024 channels)
• Neuropixels Probes (Windows only, supports up to 6144 channels)

The GUI is based around a plugin architecture, meaning the data processing modules are compiled separately from the main application. This greatly simplifies the process of adding functionality, since new modules can be shared without the need to re-compile the entire application.

Our primary user base is scientists performing electrophysiology experiments with tetrodes or silicon probes, but the GUI can also be adapted for use with other types of sensors.

Important Information

• The Open Ephys GUI is free, collaboratively developed, open-source software for scientific research. It includes many features designed to make extracellular electrophysiology data easier to acquire; however, it is not guaranteed to work as advertised. Before you use it for your own experiments, you should test any capabilities you plan to use. The use of a plugin-based architecture provides the flexibility to customize your signal chain, but it also makes it difficult to test every possible combination of processors in advance. Whenever you download or upgrade the GUI, be sure to test your desired configuration in a "safe" environment before using it to collect real data.

• If you observe any unexpected behavior, please report an issue as soon as possible. We rely on help from the community to ensure that the GUI is functioning properly.

• Any publications based on data collected with the GUI should cite the following article: Open Ephys: an open-source, plugin-based platform for multichannel electrophysiology. Citations remain essential for measuring the impact of scientific software, so be sure to include references for any open-source tools that you use in your research!

Installation

The easiest way to get started is to download the installer for your platform of choice:

• Windows
• Ubuntu/Debian
• macOS

It’s also possible to obtain the binaries as a .zip file for Windows, Linux, or Mac.

Detailed installation instructions can be found here.

To compile the GUI from source, follow the platform-specific instructions in the Developer Guide.

Funding

The Open Ephys GUI was created by scientists in order to make their experiments more adaptable, affordable, and enjoyable. Therefore, much of the development has been indirectly funded by the universities and research institutes where these scientists work, especially MIT, Brown University, and the Allen Institute.

Since 2014, the support efforts of Aarón Cuevas López have been funded by revenue from the Open Ephys store, via a contract with Universidad Miguel Hernández in Valencia.

Since 2019, the support efforts of Pavel Kulik and Anjal Doshi have been funded by a BRAIN Initiative U24 Award to the Allen Institute (U24NS109043).

How to contribute

We welcome bug reports, feature recommendations, pull requests, and plugins from the community. For more information, see Contributing to the Open Ephys GUI.

If you have the potential to donate money or developer time to this project, please get in touch via [email protected]. There are plenty of opportunities to get involved.

plugin-gui's Issues

Build documentation incomplete

The current developer documentation on the wiki doesn't describe how the build files are generated using ProJucer, which makes it hard to extend (#83). I also can't tell how the build files for the plugins are generated, which seem to also be generated by ProJucer.

How do I build the GUI with Visual Studio 2015?

I'm unable to build plugin-GUI with Visual Studio 2015 in Windows 10. I am unable to download visual studio 2013, and would like to test out some changes I've made before I submit a pull request.

I tried opening the 2013 solution and updating it, but kept getting MSBuild error MSB8020, where it could not find v140 build tools even though they were installed. I could compile a separate toy project, which suggests that the problem is with the environment variables or configuration in the project and not with my installation of Visual Studio.

Poking around at the visual studio configuration, it looks like it was generated not by visual studios but instead by introjucer/projucer? Is there some procedure for updating the visual studio project for visual studio 2015?

Document how to get USB3 FPGA working on newer Linux distros

See #43 for a bugfix.

lfpviewer small redraw region issue

There's a refresh artifact trailing the update line by ~100px, likely just something to do with the juce redraw region calls, as soon as a complete redraw is called the image looks fine.

schedule drawing with a timer callback

right now there are cases where too many draw calls can be issued from scrolling or slider movement. Instead, set a flag for redraws and issue all redraws from a ~30Hz timer callback in a low priority thread.

get zmq replies back into matlab?

Hello, I'm using the zmqwrapper mexfile to send commands to the GUI, and I'd like a way to get the replies. For example, I'd like to know the reply to the command "GetRecordingPath." I'm using a workaround right now, where inside MyThreadFunction I fprintf the reply to a txt file, and then read the text file from within matlab. It works, but it would be much cleaner (and more robust) to return the reply through the mexfile plhs, for example. Does anybody have a suggestion for how to do this?
thanks!
-Mike

KWIKFormat doesn't link with szip on Mac OS X

I am on Mac OSX 10.11. FileReader said "File type not supported" for sample data. Apparently it failed to load the KWIKFormat plugin.

Including /usr/local/lib/libsz.a in "other linker flags" in the Xcode Project settings solved it for me. Szip is a requirement for libhdf5.

Now I am off to finally try out the open-ephys gui =)
Cheers

GUI crashes when dialog in File Reader plugin is opened on some Linux systems

To quote a post on the forum:

the issue is probably because of a weird zenity (the native dialog box utility for many Linux variants) issue. We can build the GUI to not use zenity for choosing files, as follows:

Navigate to the Builds/Linux folder (you might want to take a backup of the Makefiles, but don’t backup the Builds/Linux/builds/*).

Open the Makefile and look for the lines (there should be 2) that say
CPPFLAGS := $(DEPFLAGS) -D “LINUX=1” -D “DEBUG=1” .....

Now add anywhere the macro definition JUCE_DISABLE_NATIVE_FILECHOOSERS=1(the line may not be exactly same, you’ve to add the new macro definition to the CPPFLAGS variable) CPPFLAGS := $(DEPFLAGS) -D “LINUX=1” -D “JUCE_DISABLE_NATIVE_FILECHOOSERS=1” -D “DEBUG=1”

Do the same for Makefile.plugins.

It’s strongly recommended that you use the Introjucer for plugin development, but it suffers from the same problem (build will pass, GUI will launch, but File Chooser will hang the GUI). You’ll have to edit the makefiles in Introjucer/Builds/Linux in exactly the same way.

To make this kind-of persistent, whenever you open OE with Introjucer, just make sure the "JUCE_DISABLE_NATIVE_FILECHOOSERS=1" is present in the “Extra Preprocessor Definitions” of the Config tab > Linux Makefile, as shown. Now all plugins and the GUI would get this macro definition by default.

See https://groups.google.com/forum/#!topic/open-ephys/NydCGT48tF0 for the source of this quote.

Maximizing the Beta LFP crashes GUI with JUCE Assertion failure in juce_Image.cpp:395

OS: Ubuntu 14.04
OE Version: 9477167

To reproduce, while OE GUI is running

1. Press the box on the Beta LFP viewer plugin tab to open as separate window
2. Try to maximize window

OE crashes with infinite

JUCE Assertion failure in juce_Image.cpp:395

Some values are impossible to select in the PARAM Grid

OS: Ubuntu 14.04
OE Version: 9477167

Some channels cannot be accessed by scrolling on the side tab "PARAM" tables. For instance, look at the PARAM table for the LFP viewer in the top most position:

If I scroll, the table advances by more than two rows. This means that there are rows (e.g. 13 -17 in these images) that are not accessible for selection by clicking.

IMO, all of this would be solved by using a standard list selection element analogous to the QT combobox instead of the custom tables. These elements also come with a great deal of sanity checking capabilities so you don't have to roll your own.

Acquisition board not found (Ubuntu 16.04, XEM6010-LX45)

After unzipping a precompiled Linux binary on my Ubuntu 16.04, copying 40-open-ephys.rules to its place and restarting udev, I opened GUI and tried adding the Rhythm FPGA module to the signal chain. The FPGA (XEM6010-LX45) is connected to a USB2.0 port, but it's not being detected. Error messages are:
On GUI:

ACQUISITION BOARD NOT FOUND.
An acquisition board could not be found. Please connect one now.
[OK] [Cancel]

On console:

FrontPanel DLL loaded.  Built: Feb  1 2012  17:34:05

Scanning USB for Opal Kelly devices...

Found 0 Opal Kelly devices connected:

Device could not be opened.  Is one connected?

Yes, it is. But indeed, the FPGA doesn't show on the lsusb list (cable and USB port work fine.) Strangely, when I connect it to a USB3.0 port, it is detected, but I get a different error:

FrontPanel DLL loaded.  Built: Feb  1 2012  17:34:05

Scanning USB for Opal Kelly devices...

Found 1 Opal Kelly device connected:
  Device #1: Opal Kelly XEM6010LX45 with serial number 00000004YU

FPGA system clock: 100 MHz
Opal Kelly device firmware version: 3.1
Opal Kelly device serial number: 00000004YU�
Opal Kelly device ID string: Opal Kelly XEM6010

FPGA configuration failed: FPGA DONE signal did not assert after configuration.
Couldn't upload bitfile from /home/thiago/Programs/open-ephys-linux/rhd2000.bit

A dialog window opens, and pointing to either rhd2000.bit or rhd2000_usb3.bit leads to the same error. Anything I'm doing wrong?
Help appreciated.

Crash when GUI is closed after loading a processing chain for which the headstage is not present

OS: Ubuntu 14.04
OE Version: 9477167

• Open the GUI
• Load a previous processing chain (attached below), but don't have the appropriate headstages attached to the OE board. For this reason, the processing chain is greyed out. This is fine.
• Close the GUI window using X button
• Receive

Filters/Spike Sorter
Create subnodes with parameters
  Moving forward along signal chain.
Sinks/Spike Viewer
Create subnodes with parameters
  Moving forward along signal chain.
  No processor found.
   Processor already saved as number 5
  Moving forward along signal chain.
Sinks/LFP Viewer
Create subnodes with parameters
  Moving forward along signal chain.
  No processor found.
  End of chain.
*** Error in `./open-ephys': munmap_chunk(): invalid pointer: 0x000000000f98cca0 ***

[1]+  Stopped                 ./open-ephys

• OE GUI is stopped in background. I must be brought forward using fg and killed using SIGQUIT

Signal chain:

adjustment_00.zip

Opening the Rhythm FPGA source node takes a very long time in Linux

OS: Ubuntu 14.04
OE Version: 9477167

The GUI blocks for about 1 minute when I drag/drop the Rhythm FPGA node to the signal chain. It is completely unresponsive during this time period and mangles other windows that get dragged across it. it spends about 30 seconds in this state:

Item dropped at insertion point 0
Creating from description...
Sources::Rhythm FPGA (0-0)
/home/jon/public/open-ephys/plugin-GUI/Builds/Linux/build
---- Intan Technologies ---- Rhythm RHD2000 Controller v1.41 ----


FrontPanel DLL loaded.  Built: Feb  1 2012  17:34:05

Scanning USB for Opal Kelly devices...

and then another 30 stuck at

Found 1 Opal Kelly device connected:
  Device #1: Opal Kelly XEM6010LX45 with serial number 141000081U

Eventually, either the

1. Opal Kelly device is recognized or
2. I receive and endless stream of ...error usb control message: Cannot allocate memoryerror usb control message: Cannot allocate memory... at the terminal and I must forcibly kill the GUI (SIGQUIT) to get it to stop. This seems to happen after the GUI has crashed during acquisition previously. EDIT: this occurs every time I close the GUI, even if its through a normal mechanism. Brining the USB connection back to life requires me to unplug/plug the USB.

Incorrect restoration of record state

Here's what I'm seeing.

Steps (with a headstage attached):

• Start with a blank setup
• Add a Rhythm FPGA processor
• Disable recording for all but the first three headstage channels (so REC->none, then click 1,2 and 3)
• Enable ADC channels
• Enable recording for all ADC channels
• Save your config
• Quit, come back, load your config

Expected:
The first three headstage channels and the last eight should be set to record.

Observed:
The first three headstage channels, first three AUX channels, and first three ADC channels are set to record.

I tracked it down to GenericProcessor::update(). If you wind up generating new settings, then you wind up going through the following for loops:

for (int i = 0; i < getNumHeadstageOutputs(); i++)

for (int j = 0; j < getNumAuxOutputs(); j++)

for (int k = 0; k < getNumAdcOutputs(); k++)

These respectively set channel's recording status as follows:

if (i < recordStatus.size())
{
    ch->setRecordState(recordStatus[i]);
}

if (j < recordStatus.size())
{
    ch->setRecordState(recordStatus[j]);
}

if (k< recordStatus.size())
{
    ch->setRecordState(recordStatus[k]);
}

In light of the use of i, j and k here, the observed behavior makes sense. The first three channels in recordStatus are set to record, so the the first three channels of each type will be set to record.

The issue goes away if I use nidx, which tracks the cumulative channel index, rather than i, j and k.

I'll submit a PR after lunch.

GUI freezes when selecting files and directories

The GUI (v 0.4.1, downloaded as a binary from your open-ephys.org site) freezes on Ubuntu 16.04 (gnome) when attempting to either select a file with the file reader source, or changing the directory using the top drawer menu.

LFP viewer does not draw in own-window mode

I compiled the plugin-GUI from source (commit 9477167) on Ubuntu 14.04. When used as a tab, the LFP viewer works fine. When used as a separate window, the viewer does not draw. Sometimes, the viewer will draw but not update unless I grab the window and move it around on the screen.


Here is the signal chain I am using:
http://pastebin.com/gXdjzWm5

Please let me know if there is any more information I can give you.

Digital fast settle command not working in windows

Hi,

I'd like to command the headstage (RHD2132 16-channel from Intan) to fast settle after a stimulation artifact that appears to saturate headstage output. When I set a digital input channel to control the TTL fast settle in the rhythm FPGA source on the open ephys GUI and provide a digital input through this channel with the pulse pal, amplifier output remains unchanged, but the digital input is detected and reported as an event by the GUI. I'm running Windows 7 enterprise; running the GUI as an administrator didn't change performance. Is there something else I need to do to control the fast settle command for our headstage?

Thanks very much,
Michelle

DataBuffer::addToBuffer numItems... useless, or just misunderstood?

Unless I'm mistaken (definitely possible), the numItems argument from DataBuffer::addToBuffer() is confusing and potentially dangerous. Looking at the method's body (copied below) and calls to it throughout the code, the assumption seems to be that numItems will always be 1, as this is the case in all un-commented calls to it, and since buffer.copyFrom() gets called with numSamples=1.

The problem is, if you try to call addToBuffer() with anything other than numItems=1 and one sample per channel in data argument, two unfortunate things happen (I think...):

1. abstractFifo.prepareToWrite() and abstractFifo.finishedWrite() get misinformed about the number of buffer positions being used (see (2)). Unless there's something going on I'm not appreciating, this will lead to gaps in the buffer that don't get written, but do get read.
2. The for loop (see below) only reads one sample per channel into the buffer, so if the method gets called with more than that, everything beyond the first sample is quietly ignored.

I'd be happy to contribute a version of addToBuffer that can take more than one sample per channel, and to provide a separate method that unambiguously does what the current implementation does (takes one sample per channel). It seems like it'd make addToBuffer safer and easier to use, and would be reverse compatible with any code that currently uses addToBuffer correctly (which includes everything in master). Whaddya think?

void DataBuffer::addToBuffer(float* data, int64* timestamps, uint64* eventCodes, int numItems)
{
    // writes one sample for all channels
    int startIndex1, blockSize1, startIndex2, blockSize2;
    abstractFifo.prepareToWrite(numItems, startIndex1, blockSize1, startIndex2, blockSize2);

    for (int chan = 0; chan < numChans; chan++)
    {

        buffer.copyFrom(chan, // int destChannel
                        startIndex1, // int destStartSample
                        data + chan,  // const float* source
                        1); // int num samples
    }

    *(timestampBuffer + startIndex1) = *timestamps;
    *(eventCodeBuffer + startIndex1) = *eventCodes;

    abstractFifo.finishedWrite(numItems);
}

Error with NetworkEvents

I'm using the latest master version of the GUI on Ubuntu 16.04.

I've created a simple chain with FileReader (sourcing one of the example files), NetworkEvents and Splitter. When I start acquisition, it works fine, I'm able to send messages using network_events_console.py and they show up at the bottom of the GUI. However, when I start recording, no matter if I'm connected or not, I get the following error: terminate called after throwing an instance of 'std::out_of_range' what(): map::at
This is the Valgrind trace:

==4252== Process terminating with default action of signal 6 (SIGABRT)
==4252==    at 0x6AA0418: raise (raise.c:54)
==4252==    by 0x6AA2019: abort (abort.c:89)
==4252==    by 0x625984C: __gnu_cxx::__verbose_terminate_handler() (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.21)
==4252==    by 0x62576B5: ??? (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.21)
==4252==    by 0x6257700: std::terminate() (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.21)
==4252==    by 0x6257918: __cxa_throw (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.21)
==4252==    by 0x62802BE: std::__throw_out_of_range(char const*) (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.21)
==4252==    by 0x59FE31: at (stl_map.h:523)
==4252==    by 0x59FE31: RecordNode::process(juce::AudioSampleBuffer&, juce::MidiBuffer&) (RecordNode.cpp:459)
==4252==    by 0x6A219C: juce::GraphRenderingOps::ProcessBufferOp::perform(juce::AudioSampleBuffer&, juce::OwnedArray<juce::MidiBuffer, juce::DummyCriticalSection> const&, int) (juce_AudioProcessorGraph.cpp:226)
==4252==    by 0x6974F3: juce::AudioProcessorGraph::processBlock(juce::AudioSampleBuffer&, juce::MidiBuffer&) (juce_AudioProcessorGraph.cpp:1316)
==4252==    by 0x6AB074: juce::AudioProcessorPlayer::audioDeviceIOCallback(float const**, int, float**, int, int) (juce_AudioProcessorPlayer.cpp:129)
==4252==    by 0x60FCA7: juce::AudioDeviceManager::audioDeviceIOCallbackInt(float const**, int, float**, int, int) (juce_AudioDeviceManager.cpp:728)

The line in RecordNode::process is int nSamples = numSamples.at(sourceNodeId); inside a for loop going over all record channels.

This seems to be a problem with NetworkEvents, unless I am somehow creating the chain incorrectly, however it works well when only doing the acquisition.

Signal chain not processing when unplugging USB sound card

At least on Windows, if a USB sound card is plugged and set as the default sound device when the GUI starts but is disconnected afterwards the GUI will not generate acquisition callbacks so acquisition and processing will not work. GUI elements will still show that acquisition is running and the timer will be counting, but the signal chain will not do any processing or acquisition. Haven't tested on other OS,

The workaround is to open the audio settings window and selecting another sound card (the selection box will show << none >> to reflect that the sound card it was using does not exist in the system anymore).

Buffer size interface button not visible in release v0.4.1

In the current binaries (on Mac at least), the buffer size button in the control panel is invisible (but still can be clicked). It should be an easy fix, but I wanted to make a record of it here.

Loading/saving plugin parameters

It would be quite useful to be able to load/save parameters for single plugins (not just the whole configuration). I couldn't find any dedicated function in the GUI. However, as I understand this can easily be done by calling the saveToXml and saveToXml and loadFromXml functions of the plugin, e.g., by adding load/save items to the context menu of a plugin (right click on plugin title bar).

@aacuevas: if this doesn't sound like an awfully bad idea I would go ahead and implement this in the GUI.

Arne

Clicking "none" in channel map side tab silently deletes reference channel

OS: Ubuntu 14.04
OE Version: 9477167

In the channel map component

1. Select a reference channel using the "PARAM" Tab in the side tab of the component
2. Go to the Audio Tab.
3. Select a channel in Audio tab for listening through speakers.
4. Press "none" while still in Audio tab
5. Reference channel subtraction is no long applied. In the "PARAM" tab, the reference channel is still selected even though its not doing anything.

Make lib locations on mac environment dependent

On macs, the location of several libraries changes depending on how you install them (using MacPorts versus HomeBrew, for example). Right now, the project configurations always point to /opt/local, so anyone working on them who uses homebrew has to edit the configs to point to /usr/local, then remember not to commit those changes, and to stash and re-apply them whenever updating a branch. It's a little cumbersome.

In the pull request below, I add a build variable called MAC_PACKAGE_DIR whose default value is /opt/local, and replace every mention of "/opt/local" in project config files with $(MAC_PACKAGE_DIR). I also add Env.xcconfig.example, which includes instructions on how to create Env.xcconfig, which can be used to override the value of MAC_PACKAGE_DIR.

I've tested that the project will build with and without Env.xcconfig present. Note that after adding or removing the file, it sometimes takes a reload of the workspace or re-saving Plugin.xcconfig (without changes) to get the projects to pick up the new value of MAC_PACKAGE_DIR, but this only has to be done once.

Absolute paths in JuliaProcessor prevent compilation

I am unable to compile the development branch on Ubuntu 16.04.1 LTS 64-bit due to the JuliaProcessor plugin using absolute paths to specify locations.

Here is the error I get when I attempt to build the plugins:

Compiling JuliaEditor.cpp
Building JuliaProcessor.so
g++: error: /home/jvoigts/Documents/Github/julia//usr/lib: No such file or directory

There are references to /home/jvoigts... in at least three files:

~/D/C/p/S/P/JuliaProcessor ❯❯❯ grep -rl /home/jvoigts ./
Makefile
JuliaEditor.cpp
JuliaProcessor.cpp

No waveform length indication in OE spike file header

In the headers produced using the Open Ephys data format for spikes, there is no indication of spike waveform length in the header. This is pretty useful information for efficient parsing. The waveform length should be added by the following member function of /Source/Processors/RecordNode/OriginalRecording.cpp

String OriginalRecording::generateSpikeHeader(SpikeRecordInfo* elec)

However, the SpikeRecordInfo struct defined in /Source/Processors/RecordNode/RecordEngine.h is missing a num_samples data member. I think this should be added to to the SpikeRecordInfo struct s.t. this information can propagate into the OE spike file header.

Immediate Seg fault after successful compile

Hi,
I've tried compiling the development branch of plugin-GUI and it succeeds with both make and making the plugins. However there is an immediate segmentation fault (core dumped) after the command line output shows JUCE v3.0.6 and "Created processor graph.' I'm using Ubuntu 12.04LTS (fully upgraded) and have successfully compiled and used the last non-plugin GUI 0.3.6 on my system. Any suggestions on how to debug this? What is the test system in Linux that you are using for development?
Thanks,
Linus

GUI crashes on fast movement of threshold slider.

Hi,

I used the GUI for the first time and found an issue. In spike detector module, if the threshold slider is moved fast or is moved to 0, the GUI gets hanged. Also, the slider gets distorted and a rectangle is seen instead of the original slider (when moved to 0). It would be great if someone could help me fix this.

Thanks,
Kushagra

Documentation of XML files?

I'm trying to understand the settings.xml and Continuous_Data.openephys xml files produced by the plugin gui. There are a number of XML elements and parameters that are not in the data format specification nor in the interfaces and standards wiki page. I tried look in the source code of OriginalRecording.cpp and .h, but couldn't find any other helpful information there.

Specifically, I am wondering about the following parameters:

in the Continuous_Data.openephys file:

• number parameter of EXPERIMENT element
• separatefiles parameter of EXPERIMENT element
• number parameter of RECORDING element (is this the same as the recording numbers in the binary files?)

in the settings.xml file file:

• SampleRate parameter in the EDITOR child of "Sources/Rhythm FPGA" PROCESSOR element.

Is there always only one experiment? Is a new RECORDING element made each time the record button is pressed in the GUI, or does the RECORDING element span multiple recordings?

Can't upload bitfile to XEM6010

Hi,
I am trying to use an acquisition board v2.1 (rev3) with an Opal Kelly XEM6010-LX150 on windows 10 64bit. I followed the installation instructions from the wiki and the Front Panel Device seems to be recognised OK as it shows up in device manager.

However, I am getting an error saying FPGA bitfile not found saying the rhd2000.bit was not found in the directory. The output of the console (below) suggests that maybe it was found, but it didn't receive confirmation of the upload?

Scanning USB for Opal Kelly devices...

Found 1 Opal Kelly device connected:
  Device #1: Opal Kelly XEM6010LX150 with serial number 1243000461

FPGA system clock: 100 MHz
Opal Kelly device firmware version: 3.1
Opal Kelly device serial number: 1243000461
Opal Kelly device ID string: Opal Kelly XEM6010

FPGA configuration failed: FPGA DONE signal did not assert after configuration.
Couldn't upload bitfile from C:\Users\Jimbles\Downloads\windows-64-master\rhd2000.bit

We have tried this on 2 PCs (both windows 10 64bit though) and have had no luck. The only other thing that is different is the 5V power supply, which is a 2250mA power supply from Maplin, not the one supplied with the board.

Thanks!

Data type clash between JUCE and other libraries

It seems that there is some data type clash between juce's int64 and the int64 type used by other libraries, e.g., opencv. However, adding juce's namespace to all int64 definitions in CoreServices.h/CoreServices.cpp solves this issue, i.e. int64 -> juce::int64. Given that user-contributed plugins will likely use external libraries it seems a good idea to fix it in the next update. The functioning of the GUI is not affected by this as it is using juce's namespace by default.

open ephys process stops when trying to change save directory in Linux

OS: Ubuntu 14.04
OE Version: 9477167

Sometimes, when I try to open the folder selection dialog to change the directory in which data will be saved by clicking the ellipses button next to the current save path:

Open ephys stops responding. When I check the command line, I see that OE GUI has dropped into the background and no folder selection dialog has appeared (it is not 'behind the GUI' which I think is known bug on some Linux DE's).

Disabling LFP Viewer Beta
Ending animation.
Filter Viewport enabled.

[1]+  Stopped                 ./open-ephys
build[1]$ fg
./open-ephys

Brining the process to the foreground causes it to hang. It must be killed with SIGQUIT

GUI freeze on file open dialog in Ubuntu

I'm using the open ephys plugin GUI complied from source. Commit SHA: 2b33286. I'm using ubuntu 16.04 and have produced the following issue with both the GNOME desktop environment and the Unity DE. When I try to open a configuration file, the GUI hangs and no file dialog window appears. My labmate has noticed that in the LXDE Desktop environment, the dialog will open, but will open behind the Open Ephys main window (not in focus). Maybe these two things are related.

I am therefore forced to restart the GUI after trying to load a configuration file.

Segfault when AUX ADC inputs are activated after signal chain involving beta LFP viewer has been defined

OS: Ubuntu 14.04
OE Version: 9477167

To reproduce

1. Load the signal chain attached to the bottom of this report
2. After signal chain has loaded, enable the AUX ADCs on the rhythm FPGA source node
3. Press play
4. Receive

...
Resizing buffer. Samples: 600000, Inputs: 139
   Enabling VisualizerEditor
Beginning animation.
Filter Viewport disabled.
[New Thread 0x7fffe9cb3700 (LWP 9746)]
[Thread 0x7fffe9cb3700 (LWP 9746) exited]
[New Thread 0x7fffe9cb3700 (LWP 9747)]
[New Thread 0x7fffe94b2700 (LWP 9748)]

Adding audio callback.

Program received signal SIGSEGV, Segmentation fault.
0x00007fffedff0b5c in LfpDisplayNodeBeta::LfpDisplayCanvas::updateScreenBuffer (this=0xb1c9e50) at LfpDisplayCanvas.cpp:1046
1046                                    samplesPerPixel[channel][sbi][c]=sample_current;

The following procedure fixes the segfault

1. Load processing chain
2. Remove all Beta LFP viewers
3. Enable the AUX ADCs on the rhythm FPGA source node
4. Re-add the Beta LFP viewer

ca1-recording.oesettings.zip

[Development branch] OpenEphysHDF5Lib.so errors

Hello!

After compiling the GUI (with no errors), when I load the GUI I got the following errors:

[...]
Loading Plugin: NWBFormat... ../../Source/Processors/PluginManager/PluginManager.cpp:177: Failed to load plugin DLL: OpenEphysHDF5Lib.so: cannot open shared object file: No such file or directory
 DLL Load FAILED
[...]
Loading Plugin: KWIKFormat... ../../Source/Processors/PluginManager/PluginManager.cpp:177: Failed to load plugin DLL: OpenEphysHDF5Lib.so: cannot open shared object file: No such file or directory
 DLL Load FAILED
[...]

As a consequence, I can only save data in OpenEphys and Binary formats.
In the build folder there is an OpenEphysHDF5Lib.so file:

$ ls build/
intermediate    libokFrontPanel.so   open-ephys.so  rhd2000.bit
lastConfig.xml  OpenEphysHDF5Lib.so  plugins        windowState.xml

Should I link this file somewhere before/after compiling?

HDF5 libraries are working fine in my system. I can read and write hdf5 files, and stable GUI compiles and saves data in KWIK format. Here is some info on the system:

$ sudo find / -type f -iname libhdf5*
/usr/lib64/libhdf5hl_fortran.so.10.0.3
/usr/lib64/libhdf5_cpp.so.13.0.0
/usr/lib64/libhdf5.so.10.2.1
/usr/lib64/libhdf5_hl_cpp.so.11.1.0
/usr/lib64/libhdf5_fortran.so.10.0.4
/usr/lib64/libhdf5.settings
/usr/lib64/libhdf5_hl.so.10.1.1

$ uname -a
Linux LeaoLabGentoo 4.8.14-rt-rt9 #2 SMP PREEMPT RT Tue Jan 17 12:33:17 BRST 2017 x86_64 Intel(R) Xeon(R) CPU E3-1280 V2 @ 3.60GHz GenuineIntel GNU/Linux

Thanks!

Events are not being saved for multiple datasets in Kwik

I'm using multiple datasets recordings. After running some tests, I noticed that the events are not being saved for all datasets, only for the last one. I recorded 8 datasets, each should have four events (two TTL pulses).

Steps I followed:

• Connected a 16Ch headstage, two ADC channels and two TTL channels;
• Added FPGA, RecordControl and LFPViewerBeta modules to signal chain;
• Activated ADCs and changed 32 to 16ch in FPGA module;
• Set FPGA module to record only channels 1, 20 and 21 (one from headstage and two from ADCs);
• Set RecordControl to Edge toggle, Ch8, Rising;
• Set to save as Kwik and set path;
• Play;
• Used TTLs on digital input 8 to start and stop recordings

Actual result:
A .kwe with event info only from the last dataset (other files are ok).

In [1]: import h5py

In [2]: FileName = 'KwikFiles/2016-06-22_14-04-26/experiment1.kwe'

In [3]: F = h5py.File(FileName, 'r')

In [4]: list(F['recordings'])
Out[4]: ['0', '1', '2', '3', '4', '5', '6', '7']

In [5]: list(F['event_types']['TTL']['events']['recording'])
Out[5]: [7, 7, 7, 7, 7, 7, 7, 7, 7, 7]

Expected results (for example, a recording I did months ago):
A .kwe with all event info from all datasets (between other files).

In [6]: X = h5py.File('../../KwikFiles/2016-03-29_17-16-56/experiment1.kwe', 'r')

In [7]: list(X['recordings'])
Out[7]: ['0', '1', '2', '3', '4', '5', '6', '7']

In [8]: print(list(X['event_types']['TTL']['events']['recording']))
[0, 0, 0, 0, 1, 1, 1, 1, 2, 2, 2, 2, 3, 3, 3, 3, 4, 4, 4, 4, 5, 5, 5, 5, 6, 6, 6, 6, 7, 7, 7, 7]

In both recordings I recorded 1 headstage channel + 2 ADC channels. The TTL channels used were also the same.

If I git clone https://github.com/open-ephys/plugin-GUI, git reset --hard 723b328 (a random commit from 28/03/2016) and compile, then events are saved as expected.

Cheers :)

Vertical artifacts in LFP Viewer

Every 10 (now 20) seconds, a 1-pixel vertical line appears in the LFP Viewer across all channels. Likely due to reaching the end of the 10-second display buffer.

not totally fixed but mostly usable now, in 0488eaa
there is still a small display issue if the end of the display
buffer is hit because now only 1-2samples are associated with the pixel
and this causes the min/max and histogram displays to look odd.
shouldn’t be a big issue in real applications but worth fixing when we
inevitably refactor this whole plugin.

this is due to reaching the end of the displaybuffer

.cpp files could use brief descriptions

I'm trying to figure out what files do what in the source, and I've noticed that most or all of the .cpp files have the same generic GPL message at the top. Maybe this is my Python side talking, but it would be really useful to have a brief description of what each file does/is for in a one- or two-line comment at the top, especially for newcomers.

Can't compile with gcc 6

I upgraded to gcc 6.2.1 and can no longer compile the GUI. I think this might be a problem upstream in JUCE. My searching turned up this JUCE forum post that didn't get any useful response, and this discussion of what might be a similar issue affecting a different package.

Has anyone else upgraded gcc and had this issue? I'm working on downgrading to gcc 5.3, to confirm that the gcc version is what caused the problem.

The full errors are here:

Compiling juce_audio_formats.cpp
In file included from ../../JuceLibraryCode/modules/juce_audio_formats/codecs/juce_FlacAudioFormat.cpp:78:0,
                 from ../../JuceLibraryCode/modules/juce_audio_formats/juce_audio_formats.cpp:110:
../../JuceLibraryCode/modules/juce_audio_formats/codecs/flac/libFLAC/lpc_flac.c: In function ‘long int juce::FlacNamespace::lround(double)’:
../../JuceLibraryCode/modules/juce_audio_formats/codecs/flac/libFLAC/lpc_flac.c:65:39: error: ‘long int juce::FlacNamespace::lround(double)’ conflicts with a previous declaration
 static inline long int lround(double x) {
                                       ^
In file included from /usr/include/features.h:368:0,
                 from /usr/include/sched.h:22,
                 from ../../JuceLibraryCode/modules/juce_audio_formats/../juce_core/native/juce_BasicNativeHeaders.h:168,
                 from ../../JuceLibraryCode/modules/juce_audio_formats/juce_audio_formats.cpp:38:
/usr/include/bits/mathcalls.h:348:1: note: previous declaration ‘long int lround(double)’
 __MATHDECL (long int,lround,, (_Mdouble_ __x));
 ^
In file included from ../../JuceLibraryCode/modules/juce_audio_formats/codecs/juce_FlacAudioFormat.cpp:78:0,
                 from ../../JuceLibraryCode/modules/juce_audio_formats/juce_audio_formats.cpp:110:
../../JuceLibraryCode/modules/juce_audio_formats/codecs/flac/libFLAC/lpc_flac.c: In function ‘int juce::FlacNamespace::FLAC__lpc_quantize_coefficients(const FLAC__real*, unsigned int, unsigned int, juce::FlacNamespace::FLAC__int32*, int*)’:
../../JuceLibraryCode/modules/juce_audio_formats/codecs/flac/libFLAC/lpc_flac.c:218:20: error: call of overloaded ‘lround(juce::FlacNamespace::FLAC__double&)’ is ambiguous
    q = lround(error);
                    ^
In file included from ../../JuceLibraryCode/modules/juce_audio_formats/../juce_audio_basics/../juce_core/system/juce_StandardHeader.h:66:0,
                 from ../../JuceLibraryCode/modules/juce_audio_formats/../juce_audio_basics/../juce_core/juce_core.h:143,
                 from ../../JuceLibraryCode/modules/juce_audio_formats/../juce_audio_basics/juce_audio_basics.h:28,
                 from ../../JuceLibraryCode/modules/juce_audio_formats/juce_audio_formats.h:28,
                 from ../../JuceLibraryCode/modules/juce_audio_formats/juce_audio_formats.cpp:39:
/usr/include/c++/6.2.1/cmath:1594:3: note: candidate: constexpr long int std::lround(long double)
   lround(long double __x)
   ^~~~~~
In file included from /usr/include/features.h:368:0,
                 from /usr/include/sched.h:22,
                 from ../../JuceLibraryCode/modules/juce_audio_formats/../juce_core/native/juce_BasicNativeHeaders.h:168,
                 from ../../JuceLibraryCode/modules/juce_audio_formats/juce_audio_formats.cpp:38:
/usr/include/bits/mathcalls.h:348:1: note: candidate: long int lround(double)
 __MATHDECL (long int,lround,, (_Mdouble_ __x));
 ^
In file included from ../../JuceLibraryCode/modules/juce_audio_formats/../juce_audio_basics/../juce_core/system/juce_StandardHeader.h:66:0,
                 from ../../JuceLibraryCode/modules/juce_audio_formats/../juce_audio_basics/../juce_core/juce_core.h:143,
                 from ../../JuceLibraryCode/modules/juce_audio_formats/../juce_audio_basics/juce_audio_basics.h:28,
                 from ../../JuceLibraryCode/modules/juce_audio_formats/juce_audio_formats.h:28,
                 from ../../JuceLibraryCode/modules/juce_audio_formats/juce_audio_formats.cpp:39:
/usr/include/c++/6.2.1/cmath:1590:3: note: candidate: constexpr long int std::lround(float)
   lround(float __x)
   ^~~~~~
In file included from ../../JuceLibraryCode/modules/juce_audio_formats/codecs/juce_FlacAudioFormat.cpp:78:0,
                 from ../../JuceLibraryCode/modules/juce_audio_formats/juce_audio_formats.cpp:110:
../../JuceLibraryCode/modules/juce_audio_formats/codecs/flac/libFLAC/lpc_flac.c:65:24: note: candidate: long int juce::FlacNamespace::lround(double)
 static inline long int lround(double x) {
                        ^~~~~~
In file included from ../../JuceLibraryCode/modules/juce_audio_formats/codecs/juce_FlacAudioFormat.cpp:78:0,
                 from ../../JuceLibraryCode/modules/juce_audio_formats/juce_audio_formats.cpp:110:
../../JuceLibraryCode/modules/juce_audio_formats/codecs/flac/libFLAC/lpc_flac.c:247:20: error: call of overloaded ‘lround(juce::FlacNamespace::FLAC__double&)’ is ambiguous
    q = lround(error);
                    ^
In file included from ../../JuceLibraryCode/modules/juce_audio_formats/../juce_audio_basics/../juce_core/system/juce_StandardHeader.h:66:0,
                 from ../../JuceLibraryCode/modules/juce_audio_formats/../juce_audio_basics/../juce_core/juce_core.h:143,
                 from ../../JuceLibraryCode/modules/juce_audio_formats/../juce_audio_basics/juce_audio_basics.h:28,
                 from ../../JuceLibraryCode/modules/juce_audio_formats/juce_audio_formats.h:28,
                 from ../../JuceLibraryCode/modules/juce_audio_formats/juce_audio_formats.cpp:39:
/usr/include/c++/6.2.1/cmath:1594:3: note: candidate: constexpr long int std::lround(long double)
   lround(long double __x)
   ^~~~~~
In file included from /usr/include/features.h:368:0,
                 from /usr/include/sched.h:22,
                 from ../../JuceLibraryCode/modules/juce_audio_formats/../juce_core/native/juce_BasicNativeHeaders.h:168,
                 from ../../JuceLibraryCode/modules/juce_audio_formats/juce_audio_formats.cpp:38:
/usr/include/bits/mathcalls.h:348:1: note: candidate: long int lround(double)
 __MATHDECL (long int,lround,, (_Mdouble_ __x));
 ^
In file included from ../../JuceLibraryCode/modules/juce_audio_formats/../juce_audio_basics/../juce_core/system/juce_StandardHeader.h:66:0,
                 from ../../JuceLibraryCode/modules/juce_audio_formats/../juce_audio_basics/../juce_core/juce_core.h:143,
                 from ../../JuceLibraryCode/modules/juce_audio_formats/../juce_audio_basics/juce_audio_basics.h:28,
                 from ../../JuceLibraryCode/modules/juce_audio_formats/juce_audio_formats.h:28,
                 from ../../JuceLibraryCode/modules/juce_audio_formats/juce_audio_formats.cpp:39:
/usr/include/c++/6.2.1/cmath:1590:3: note: candidate: constexpr long int std::lround(float)
   lround(float __x)
   ^~~~~~
In file included from ../../JuceLibraryCode/modules/juce_audio_formats/codecs/juce_FlacAudioFormat.cpp:78:0,
                 from ../../JuceLibraryCode/modules/juce_audio_formats/juce_audio_formats.cpp:110:
../../JuceLibraryCode/modules/juce_audio_formats/codecs/flac/libFLAC/lpc_flac.c:65:24: note: candidate: long int juce::FlacNamespace::lround(double)
 static inline long int lround(double x) {
                        ^~~~~~
make: *** [Makefile:627: build/intermediate/Debug/juce_audio_formats_d349f0c8.o] Error 1

improve subsampling of histogram data in lfpviewer

right now there's a hard limit on the N samples/px - instead we should do every 2nd sample etc for large numbers in order to sample more reliably and keep the cpu load down a bit.

Mouse pointer location offset for large channel counts in channel mapper component

OS: Ubuntu 14.04
OE Version: 9477167

Note: Moved from #61

I've experienced some strangeness when selecting channels in the channel map component that may be related. When I try to drag a channel that is > 64, the mouse must hover beneath all the channel numbers (like where the channel would have been located before I scrolled the grid down). Look at this image

My mouse does not show up in the screenshot, but you can see its position which is at the hovering 89. You can see where this channel will be inserted if I was to release the left mouse button in the grid way above where the mouse is. Additionally, you can see an extra row of numbers shooting out the top of the grid

How to link multiple plugins with common libraries?

This issue has been brought up in PR #57, and I'm giving it a separate thread here.

In the process of developing a new plugin, I've realized that I need to give it some of the filtering functionality that is currently available to the FilterNode plugin through the Dsp library, which lives in the FilterNode source directory. However, I don't want to duplicate code, and I'm fairly sure that copying-and-pasting this library into the source of another plugin would create namespace clashes and linking errors. Thus, I'm trying to figure out how one could share a library between multiple plugins without disrupting the plugin architecture.

It seems that the natural solution would be to compile this library into a separate shared library file (.lib/.so/.dylib), and then have it be available when compiling the plugins that need it (and do the same with any other libraries that need to be shared). Since it would be messy to try to make that work with the way plugins are compiled now, maybe a better way is to somehow incorporate needed libraries into the main OpenEphys build? I know NetworkEvents, EventBroadcaster and I think one other plugin share ZeroMQ and get around this by requiring ZeroMQ to be installed as a prerequisite (at least on Linux?) but that obviously isn't an option for all libraries.

Thanks,
Ethan

Kwik files should store bit volts values as datasets, not attributes

The h5py library can't read array attributes properly, so these values are inaccessible in Python.

The easiest fix is to store the per-channel bit volts (and sample rate) values as datasets, rather than attributes.

This was the source of the problems discussed here: https://groups.google.com/forum/#!searchin/open-ephys/python$20kwik/open-ephys/cpEoIYLYBgU/lfL2AQSkb3AJ

Jack audio support?

Hej!

I'm using Jack connection toolkit, and I was trying to make the plugin-GUI to connect to Jack, and not to Alsa, but without success. Juce supports Jack, and even has a flag (JUCE_JACK), I just don't know where to apply it. I tried on the Makefile, but it didn't work (it compiles, but the gui still tries to connect directly to Alsa). Could you help me to understand where in the code Open-ephys is set to use Alsa, and where audio parameters like rate, buffer size and number of frames are set?

Thanks a lot!

Write spikes from spike detector nodes

Nodes that identify spikes should be responsible for passing them to the RecordNode, and their editors should provide the UI for controlling which spikes gets written.

Right now, spikes get passed to the record node from SpikeDisplayNode. It doesn't seem like that should be the responsibility of SpikeDisplayNode, for one because there are other spike data display nodes coming along (SpikeRaster, perhaps a TriggeredAverageNode), and it's not clear why one kind of spike data displaying node in particular has the privilege of recording the data.

If it doesn't conflict with any current plans, I'd be happy to do the work on this. I think it'd roll out in two phases:

1. Move the current logic into SpikeSorter
2. Build out some UI for choosing which spikes to record. Nothing fancy at this point, just a solid foundation. I'm thinking a checkboxy-thing that's always there for 'unsorted,' then checkboxes that appear /disappear as you add/remove units. Simple but clear.

Whaddya think?

(edit: grammar)

Error in VS for debug Gui RHA2000

Hi, I´m trying to install the open-ephys in Windows 7, but when I debug the open-ephys.sln It mark 2 errors that it didnt found:
Source/Processors/DataThreads/IntanThread.cpp
Source/Processors/SourceNode/SourceNode.cpp

But I have this two sources...So, I dont know whats is going on with that.

I appreciate the help!

Freeze with failure to write in OSX 10.11.6

I recently have been trying to do longer recordings, albeit at lower acquisition rates, but keep running into the same stability problem running pluggin-GUI 0.4.1: after a variable amount of time, but usually within 2 hours, the sweep on the LFP viewer freezes though the recording time continues to increase, as if I had hit pause. Data, however, is no longer being recorded- I lose anything after the freeze. This has happened with multiple machines (one 2012 iMac, a Mac mini) with multiple independent builds from source as well as from the binaries. This is a new problem since switching to pluggin-GUI from the older GUI. I'm not seeing any error messages, and if I hit a timestamp, it will still write to the message file, though the timestamp was significantly off (this was during a stress test, timestamp was at minute 400 in an 800 minute recording)- it appears that primarily the Ephys/EEG data is lost. Has anyone else run into this?

Update:
Looking over the debugging messages I'm getting a couple of failures/errors when first loading the program-

Loading Plugin: NetworkEvents... 2016-09-20 11:31:27.673 open-ephys[6037:278824] Error loading /Users/Andrew/Downloads/plugin-GUI-master/Builds/MacOSX/build/Debug/open-ephys.app/Contents/PlugIns/NetworkEvents.bundle/Contents/MacOS/NetworkEvents: dlopen(/Users/Andrew/Downloads/plugin-GUI-master/Builds/MacOSX/build/Debug/open-ephys.app/Contents/PlugIns/NetworkEvents.bundle/Contents/MacOS/NetworkEvents, 262): Symbol not found: _crypto_box
Referenced from: /Users/Andrew/Downloads/plugin-GUI-master/Builds/MacOSX/build/Debug/open-ephys.app/Contents/PlugIns/NetworkEvents.bundle/Contents/MacOS/NetworkEvents
Expected in: flat namespace
in /Users/Andrew/Downloads/plugin-GUI-master/Builds/MacOSX/build/Debug/open-ephys.app/Contents/PlugIns/NetworkEvents.bundle/Contents/MacOS/NetworkEvents
/Users/Andrew/Downloads/plugin-GUI-master/Source/Processors/PluginManager/PluginManager.cpp:194: Failed to load function 'getLibInfo'
DLL Load FAILED
...
Plugin path not found: /Users/Andrew/Library/Application Support/open-ephys/PlugIns
...
Loading Plugin: EventBroadcaster... 2016-09-20 11:31:27.409 open-ephys[6037:278824] Error loading /Users/Andrew/Downloads/plugin-GUI-master/Builds/MacOSX/build/Debug/open-ephys.app/Contents/PlugIns/EventBroadcaster.bundle/Contents/MacOS/EventBroadcaster: dlopen(/Users/Andrew/Downloads/plugin-GUI-master/Builds/MacOSX/build/Debug/open-ephys.app/Contents/PlugIns/EventBroadcaster.bundle/Contents/MacOS/EventBroadcaster, 262): Symbol not found: _crypto_box
Referenced from: /Users/Andrew/Downloads/plugin-GUI-master/Builds/MacOSX/build/Debug/open-ephys.app/Contents/PlugIns/EventBroadcaster.bundle/Contents/MacOS/EventBroadcaster
Expected in: flat namespace
in /Users/Andrew/Downloads/plugin-GUI-master/Builds/MacOSX/build/Debug/open-ephys.app/Contents/PlugIns/EventBroadcaster.bundle/Contents/MacOS/EventBroadcaster
/Users/Andrew/Downloads/plugin-GUI-master/Source/Processors/PluginManager/PluginManager.cpp:194: Failed to load function 'getLibInfo'
DLL Load FAILED
...
Does this shed any light on the underlying issue?

Thanks for the help,

A

EventBroadcaster.cpp does not compile in development branch

When I try to compile the development branch, I get the following errors from EventBroadcaster.cpp:

EventBroadcaster.cpp: In static member function ‘static std::shared_ptr<void> EventBroadcaster::getZMQContext()’:
EventBroadcaster.cpp:18:56: error: ‘zmq_ctx_new’ was not declared in this scope
     static const std::shared_ptr<void> ctx(zmq_ctx_new(), zmq_ctx_destroy);
                                                        ^
EventBroadcaster.cpp:18:59: error: ‘zmq_ctx_destroy’ was not declared in this scope
     static const std::shared_ptr<void> ctx(zmq_ctx_new(), zmq_ctx_destroy);
                                                           ^
EventBroadcaster.cpp: In member function ‘virtual void EventBroadcaster::handleEvent(int, juce::MidiMessage&, int)’:
EventBroadcaster.cpp:119:73: error: cannot convert ‘uint8_t* {aka unsigned char*}’ to ‘zmq_msg_t*’ for argument ‘2’ to ‘int zmq_send(void*, zmq_msg_t*, int)’
     if (-1 == zmq_send(zmqSocket.get(), &type, sizeof(type), ZMQ_SNDMORE) ||
                                                                         ^
EventBroadcaster.cpp:120:97: error: cannot convert ‘double*’ to ‘zmq_msg_t*’ for argument ‘2’ to ‘int zmq_send(void*, zmq_msg_t*, int)’
         -1 == zmq_send(zmqSocket.get(), &timestampSeconds, sizeof(timestampSeconds), ZMQ_SNDMORE) ||
                                                                                                 ^
EventBroadcaster.cpp:121:82: error: cannot convert ‘const uint8_t* {aka const unsigned char*}’ to ‘zmq_msg_t*’ for argument ‘2’ to ‘int zmq_send(void*, zmq_msg_t*, int)’
         -1 == zmq_send(zmqSocket.get(), buffer + 1, event.getRawDataSize() - 1, 0) /* Omit event type */)

I am using gcc version 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.2)

Memory leak on shutdown (testing branch)

On OS X, I'm getting the following message on GUI shutdown:

Leaked objects detected: 510 instance(s) of class GlyphInfo
JUCE Assertion failure in juce_LeakedObjectDetector.h:95

It happens even if I haven't added any processors—just closing the GUI immediately after running triggers it.

I poked around a little to see if I could find the source, but there wasn't anything obvious.

plugins, translation units, and multiple instances of LeakedObjectDetector's LeakCounter singletons

I thought this was going to be a simple bug...

Here's the issue:

• Build the latest development branch (I'm on a mac using xcode, but this is probably a cross-platform issue).
• Run it.
• Throw a Spike Viewer in the signal chain.
• Open the Spike Viewer's tab, make sure it has focus, then press a key on your keyboard.
• You'll hit a breakpoint, and find this waiting for you in the debug console:

*** Dangling pointer deletion! Class: KeyPress
JUCE Assertion failure in juce_LeakedObjectDetector.h:71

Bummer! But Ok, I thought, let's fix it. And that's when my weekend plans went out the window.

Long story short, usually the LeakedObjectDetector class template uses one LeakCounter singleton per class that uses the template. So in this case, there's supposed to be one LeakCounter dedicated to counting constructions and deletions of KeyPress objects. But it turns out that singleton's don't behave as you might expect when combined with a plugin architecture - each plugin (and the main app) has its own compilation unit (translation unit), and, as things stand now, we actually get one LeakCounter singleton per class that uses the LeakedObjectDetector template per translation unit. That's crazy. It makes sense, but ugh, crazy. Let's take a closer look at the craziness, just to be sure.

First things first. The issue goes away if you comment out the entire body of SpikeDisplayCanvas::keyPressed. If you then un-comment only the line

KeyPress c = KeyPress::createFromDescription("c");

... the issue returns. So, simply instantiating then deallocating a KeyPress within this method causes a false dangling pointer alert. That's weird. But check out what happens if I modify getCounter to talk to me a bit (code borrowed and modified from here):

--- a/JuceLibraryCode/modules/juce_core/memory/juce_LeakedObjectDetector.h
+++ b/JuceLibraryCode/modules/juce_core/memory/juce_LeakedObjectDetector.h
@@ -107,6 +107,13 @@ private:
     static LeakCounter& getCounter() noexcept
     {
         static LeakCounter counter;
+ 
+        static int LeakCounterCounter; 
+ 
+        if (strcmp (getLeakedObjectClassName(), "KeyPress") == 0) { 
+            DBG (String::formatted ("%d: function pointer %p, counter object: %p, value: %d", LeakCounterCounter++, getCounter, &counter, counter.numObjects.get ())); 
+        } 
+ 
         return counter;
     }
 };

If I do that, then repeat the steps above, I get:

...(omitting output prior to my keypress)
791: function pointer 0x10019fac0, counter object: 0x100942578, value: 25
0: function pointer 0x107485ca0, counter object: 0x1074910e0, value: 0
*** Dangling pointer deletion! Class: KeyPress
JUCE Assertion failure in juce_LeakedObjectDetector.h:71

Different counter objects, different function pointers... different LeakCounterCounters... ugh. If I put a breakpoint on my DBG line and stop there during the offending call, then take a look at the stack to see which ~LeakedObjectDetector is being called, I get:

BasicSpikeDisplay`juce::LeakedObjectDetector<juce::KeyPress>::~LeakedObjectDetector:

... whereas if I do the same during a call to getCounter from any use of KeyPress within the main app, I get:

open-ephys`juce::LeakedObjectDetector<juce::KeyPress>::~LeakedObjectDetector:

You can get the same thing to happen in any one of the plugins, just by creating a KeyPress object. I haven't looked at other objects that use JUCE_LEAK_DETECTOR yet.

So, what to do? We could just set JUCE_CHECK_MEMORY_LEAKS to false for plugins, but that's unsatisfying in a couple ways: it doesn't address the multiple singletons issue, and kills memory leak checking for objects only ever used in a single plugin. It seems like someone with stronger linker-fu than I might have a helpful suggestion here.

(edit: originally included wrong line from stack trace)