{"action":"created","issue":{"url":"https://api.github.com/repos/sccn/xdf/issues/3","labels_url":"https://api.github.com/repos/sccn/xdf/issues/3/labels{/name}","comments_url":"https://api.github.com/repos/sccn/xdf/issues/3/comments","events_url":"https://api.github.com/repos/sccn/xdf/issues/3/events","html_url":"https://github.com/sccn/xdf/issues/3","id":108382793,"number":3,"title":"A simple C(++) library and examples are needed.","user":{"login":"cboulay","id":303797,"avatar_url":"https://avatars.githubusercontent.com/u/303797?v=3","gravatar_id":"","url":"https://api.github.com/users/cboulay","html_url":"https://github.com/cboulay","followers_url":"https://api.github.com/users/cboulay/followers","following_url":"https://api.github.com/users/cboulay/following{/other_user}","gists_url":"https://api.github.com/users/cboulay/gists{/gist_id}","starred_url":"https://api.github.com/users/cboulay/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/cboulay/subscriptions","organizations_url":"https://api.github.com/users/cboulay/orgs","repos_url":"https://api.github.com/users/cboulay/repos","events_url":"https://api.github.com/users/cboulay/events{/privacy}","received_events_url":"https://api.github.com/users/cboulay/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":3,"created_at":"2015-09-25T18:26:22Z","updated_at":"2015-09-30T20:46:34Z","closed_at":null,"body":"LSL currently has a LabRecorder Python application that depends on a C library called `RecorderLib`. RecorderLib is not much more than a wrapper around [recording.h](https://github.com/sccn/labstreaminglayer/blob/master/Apps/LabRecorder/src/RecorderLib/RecorderLib/recording.h) that does all the heavy lifting in creating and writing to an XDF file, including making extensive use of Boost string handling and threading. Also worth mentioning, RecorderLib has proven to be a bit of a headache to maintain in its current form and there have been several mentions of moving it entirely to Python. After all, LabRecorder (a Python application) is the only program that actually uses RecorderLib.\r\n\r\nIt might be better to create a C(++) library for XDF (xdflib or libxdf), and some example applications that link to `xdflib.(lib|dll|dylib|so)`. To this end, it might be useful to look at how [EDF achieved this objective](https://github.com/Teuniz/EDFlib).\r\n\r\nWith a C library available, it could then be possible to make a relatively simple Python Ctypes wrapper, and then LabRecorder would import this wrapper. This would eliminate the need for LSL's RecorderLib. Even better, it will make it easier for us to import XDF files into Python for data analysis.\r\n\r\nI am not sure, but it is possible that the Matlab interface that exists in this repository and is duplicated in LSL might also benefit from having a generic C library, and this library might also facilitate adding XDF writing capability to Matlab.\r\n\r\nOne question worth considering before work on this gets started is whether such a C library for XDF should exist here or in the LSL repository. One benefit to keeping it here is that anyone stumbling upon XDF will have easy access to some examples on how to read/write data files without the overhead of trying to understand LSL. One benefit to keeping it with LSL is that, because LSL already depends on Boost, it will be trivial to reuse much of `recording.h` and no extra dependencies will be added.\r\n\r\nI'm willing to contribute toward this effort either way, but I would like a small discussion from @chkothe , @dmedine and @sccn  first so I know which approach will be most likely to have the greatest benefit.\r\n\r\nSome questions I have:\r\n\r\n- Are there any examples of anyone saving files in the XDF format outside of LSL?\r\n- Is there any savings to be had by combining XDF-read and XDF-write into a single library?\r\n\r\nIf the answer to the above two questions are both 'no', then XDF-write might be able to stay with LSL, and XDF-read can stay here and be made without Boost."},"comment":{"url":"https://api.github.com/repos/sccn/xdf/issues/comments/144538018","html_url":"https://github.com/sccn/xdf/issues/3#issuecomment-144538018","issue_url":"https://api.github.com/repos/sccn/xdf/issues/3","id":144538018,"user":{"login":"sccn","id":3052323,"avatar_url":"https://avatars.githubusercontent.com/u/3052323?v=3","gravatar_id":"","url":"https://api.github.com/users/sccn","html_url":"https://github.com/sccn","followers_url":"https://api.github.com/users/sccn/followers","following_url":"https://api.github.com/users/sccn/following{/other_user}","gists_url":"https://api.github.com/users/sccn/gists{/gist_id}","starred_url":"https://api.github.com/users/sccn/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/sccn/subscriptions","organizations_url":"https://api.github.com/users/sccn/orgs","repos_url":"https://api.github.com/users/sccn/repos","events_url":"https://api.github.com/users/sccn/events{/privacy}","received_events_url":"https://api.github.com/users/sccn/received_events","type":"User","site_admin":false},"created_at":"2015-09-30T20:46:34Z","updated_at":"2015-09-30T20:46:34Z","body":"To answer some more q's from the original email:\n- I have an XDF import function in Python; I think I should be able to\nshare it (but need to check license).\n- I think combining read/write functionality into a single library would be\nvery good (easier to maintain that way and presumably some pieces could be\nshared, like constant definitions for tags etc)\n- I think that library should be in the XDF repo, because XDF is not tied\nto LSL\n- I'm not sure to what extent people have been using XDF without LSL, but\nthere's certainly nothing stopping anyone as the format is very simple; I\nmyself had a shot at a simple XDF recorder inside a larger Python data\nprocessing system at some point, so that would be an example I guess.\n\nChristian\n\n\n\nOn Wed, Sep 30, 2015 at 1:37 PM, Christian Kothe <notifications@github.com>\nwrote:\n\n> I think I should mention that XDF was created to complement LSL as a\n> universal data format (and more immediately, to get the data recorded in\n> our lab stored somehow). Some of our collaborators in Graz have mainly been\n> interested in it as potential alternative to GDF, EDF and formats like\n> that.\n>\n> A C or C++ library for xdf import/export would be very nice indeed, in fact\n> I've spend half an afternoon on that at some point but couldn't go all the\n> way back then due to other commitments.\n>\n> The only reason why the LabRecorder is in Python because it was the\n> quickest way to get it implemented (and I didn't quite anticipate the\n> hassle that the Python/C++ bridge would cause in the longer run). I still\n> think that doing the LabRecorder entirely in Python (regardless of libxdf)\n> would be pretty nice because then it can be deployed and updated without\n> need for a multi-platform build process.\n>\n> Christian\n>\n> On Wed, Sep 30, 2015 at 12:47 PM, David Medine <notifications@github.com>\n> wrote:\n>\n> > As far as I know, XDF was created primarily to be a way to get data into\n> > MATLAB. Of course, it was also developed with generality in mind so that\n> > other languages (e.g. python) could handle the format. But, I don't think\n> > that anyone else has yet attempted to do this (answer to question 1).\n> >\n> > I see your reasoning behind conglomerating xdf read and write into a\n> > single C++ library that could be wrapped by python/matlab/whatever. So, I\n> > would say the answer to question 2 is 'yes but there is also a 'but'\n> which\n> > is that to do this would require a lot of work and restructuring of the\n> two\n> > projects.\n> >\n> > To be honest, I've never been totally happy with LabRecorder and I don't\n> > actually know why it is in Python and not C++. I believe this was done\n> with\n> > cross-platform ndeployment in mind, but now that I have added build\n> scripts\n> > for compiling LSL apps for both Linux and OSX, I don't see any reason for\n> > it to be a python app. Again, it works (on Windows and Linux, but not\n> OSX)\n> > so it is difficult to find the motivation to rewrite it.\n> >\n> > ps sorry for the delayed contribution to the discussion, I was out of\n> town\n> > for a few days.\n> >\n> > —\n> > Reply to this email directly or view it on GitHub\n> > <https://github.com/sccn/xdf/issues/3#issuecomment-144519421>.\n>\n> >\n>\n> —\n> Reply to this email directly or view it on GitHub\n> <https://github.com/sccn/xdf/issues/3#issuecomment-144535945>.\n>\n"}}