Updates (12/10 /2011): Plexon now offers a mex extension for Matlab which compiles on Linux and Mac. I have a Python .plx file reader available, and Huang Xin has a better one based on ctypes, part of RealTimeElectrophy.
Plexon hardware is meant to interface with Windows-only tools (including recording software). I think that for such a specialist tool running on dedicated hardware it’s reasonable to require the use of a specific platform. Very annoyingly, however, this commitment to Windows extends to reading data files (.plx in particular) generated by this equipement. Plexon support has responded to my inquiries concerning non-Windows platforms with an invitation to program the required software myself; in other words, you’re on your own. Now, there are non-official means to read .plx files outside of Windows, some of which I’ve written about before, but they are all more or less painful. Let me count the ways.
Plexon’s Matlab .plx reading toolbox hinges on a .dll file that runs only on Windows. Two toolboxes implement reading .plx files in Matlab without using Plexon’s dll. They are Chronux and FieldTrip. Unfortunately both of these implementations suffer from Matlab’s nature as a scripting language.
Let me explain how a .plx file is structured (more information is available in the Plexon SDK documentation). At the start is a header generated by the Plexon software. Following this header are blocks of a few hundred bytes each. The blocks can be of type event (TTL pulses mostly, but possibly other event types as well), spike, or continuous (wideband or LFP). With multiple electrodes and continuous data (for example a Utah array), the Plexon software multiplexes the channels. A 200-byte block from channel 1 is followed by a block from channel 2, then channel 3, etc. Between these blocks of continuous data are event and spike blocks. Importantly, there is no “table-of-contents” in a header or footer that would allow one, to, say, assemble the continuous data from channel 2 without reading the whole (potentially several gigabytes long) file a few hundred bytes at a time. As you can imagine, performing this type of IO in a scripting language like Matlab is a bad idea™. The issue is especially bad if you have wideband data since this will create huge .plx files.
FieldTrip recommends transcoding .plx files to .ddt (or to some other intermediate format) files to work comfortably in Matlab. Indeed, a .ddt file is composed of a header followed by a continuous stream of bytes that can be read with fread. The non-continuous data can be rounded up into a new, much slimmer .plx file, or in some other intermediate format like .mat, which will make things a lot easier to process. If you’re willing to bite the bullet and do this in Matlab (this might be very slow but at least you only have to do it once), then this is an acceptable solution.
If this is not acceptable solution (it’s too slow or you’re working outside of Matlab entirely), then you will need to use a plx2ddt converter. Unfortunately, a plx2ddt util does not exist for non-Windows platforms. Plexon has a Windows-only PlexUtil program; furthermore it is only offered as a GUI. Thus, you can’t write a batch file that will automate the process of transcoding from .plx to .ddt. You will need to interact with the Windows computer, either physically, through remote means, or through emulation (more on this later).
Essentially the same speed issue with the .plx format comes up with OpenElectrophy, which is written in Python and can read .plx files. OpenElectrophy uses a SQL database to store its data (MySQL I believe) which may or may not be an acceptable intermediate format to store your data.
Thus far, I’ve talked about two slow but potentially workable solutions for working with .plx files outside of Windows. Here are some other potential workarounds, all of which are annoying:
- Extracting spike data using plx2txt. This only gives timing information, however, and not spike waveforms. Furthermore it does not yield continuous data.
- Use plx2csv to first transcode the .plx data to .csv, then transcode the .csv file to your favorite format. Same issue as plx2txt, but at least for this one you have the C++ source code so you could write the functionality yourself.
- Code your own C/C++ code to do the job based on Plexon’s API. This is how plx2txt and plx2csv work. I’ve indicated how one can get plexon.h to work on non-Windows platforms here. I am not a good C programmer so anything involving memory management with dynamic structures is completely beyond me.
- Ripping out parts of OpenElectrophy, tweaking, and performing the transcoding from .plx to .ddt in Python without going through the SQL intermediate. This is the approach that I’ve used for our lab, it works but the code is ugly and highly specific to our setup. It took a lot of dicking around to modify the code to be fast enough for our purposes. Right now for our 96-channel setup with 10kHz wideband signals it runs in about 2x realtime (meaning it takes about a half hour to process an hour of recording).
Other, more speculative ideas:
- Run PlexUtil through the GUI on the Windows computer, for example through VNC from your non-Windows computer. Still requires GUI interaction.
- Run PlexUtil through Wine. Again, requires GUI interaction.
- Use plx2ctx then transcode ctx file and then figure out how to read .ctx file.
If you have a better idea, please let me know.
Image may be NSFW.
Clik here to view.
Image may be NSFW.Clik here to view.
