Plexon Matlab API now available for Linux

Regular readers of the blog will remember my previous struggles reading .plx files on platforms other than Windows. I got contacted by none other than Plexon boss Harvey Wiggins about this. I’m happy to report that they’ve posted an updated Matlab offline SDK which compiles on 32- and 64-bit Linux. It may be possible to get it to work on Mac as well, although I haven’t tried it. Kudos to Plexon for stepping up to the plate.

10 responses to “Plexon Matlab API now available for Linux”

  1. i got here from a google search for mexPlex errors and for a moment i thought this was a blog about beta testing for plexon… HA!

  2. I wrote code to read PLX files in Julia ( It is appreciably faster than Plexon’s MEX interface if you are interested in reading all channels from a file at once.

    Unfortunately, based on my correspondence with Plexon, they think there is a competitive advantage to keeping the PL2 format proprietary and they think all of their customers use MATLAB or Windows.

  3. Plexon have broken cross-platform compatibility with the latest version of the SDK that supports their new PL2 format, it compiles with warnings but all the validation tests fail…

  4. A simple added ifdef for fopen works for me with OS X 10.8.3, XCode 4.6.2 and Matlab2013a:

    #ifdef __APPLE__
    # define fopen64 fopen

    It should be easy for Plexon to update their instructions and source…

  5. the above fix also works on both 32-/64-bit versions (using 2009b; OS10.6.8; gcc-4.2). thank-you so much! you are a life-saver!

  6. All that is needed for compilation under matlab 2010a (64bit) macosx 10.6.8 (x86_64) is ():
    // special case macosx, here just override the __GNUC__ define…
    #ifdef __APPLE__
    #include “TargetConditionals.h”

    // macosx fopen works for largefiles…
    #define fopenEx fopen
    #define fseekEx fseeko
    #define ftellEx ftello
    // Other kinds of Mac OS
    // Unsupported platform

    added after line 45, as macosx uses gcc (at least 10.6 does) but uses fopen instead of fopen64…
    Interestingly the supplied source and the supplied mex files are overly restrictive in their sanity checking. But thanks to the supplied source now this is fixable, yippeh. The resulting mex file beats my mfile implementation of mexPlex by orders of magnitude… (Then again that mfile implementation made it a breeze to figure out why the new mexPlex.mex was falining with my data files…)

Leave a comment

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s