Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Python wrapper for RemoteLabRecorder #5

Open
agricolab opened this issue Oct 25, 2018 · 9 comments
Open

Python wrapper for RemoteLabRecorder #5

agricolab opened this issue Oct 25, 2018 · 9 comments

Comments

@agricolab
Copy link
Contributor

I wrote python interfaces to remote control LabRecorder (i.e. the Delmenhorst Version). This is implemented a) via the LabRecorderCLI using win32com.client.Dispatch("WScript.Shell") and b) via the LabRecorderRCS with a TCP/IP client. What would be a preferred place to share them?

@cboulay
Copy link
Contributor

cboulay commented Nov 27, 2018

I guess the win32com method is not cross-platform so I would shy away from that. Is the second cross-platform? Do you have that in a repo somewhere that I can look at?

One of the advantages of breaking out the repositories is that we have a little more freedom to add things. I think we could add a subfolder to this repo containing these types of interfaces. Would you like to make a pull request?

@tstenner
Copy link
Contributor

What does win32com offer? If it just starts LabRecorderCLI and inputs data / reads output the subprocess is a much better option.
As for b) I'm still not entirely happy because Qt only allows one-way communication so there's no good way to get the results of an action back. Also, I don't know yet what everyone wants to do - setting an output file name, starting and stopping recordings is working right now but with Chad's BIDS support and other ideas that might be coming in I suspect the current design won't hold up for long.

@agricolab
Copy link
Contributor Author

Thanks for the feedback, and @tstenner's update about the limits of QT.

I fully appreciate that the remote control interfaces to LabRecorder are early beta, and likely to change. For testing purposes, and as i want to reduce point&click for my students as much as possible, i have written the code anyways. I'm fine in attempting to update the clients as development progresses. I guess i might have to get a compilation workflow set up though, or rely on you handing me over the binaries.

a) subprocess.Popen was actually my first approach. But i could not find a way to send keystroke events like {Enter} to close the process gracefully. (see also https://stackoverflow.com/questions/3531953/send-keyboard-event-using-subprocess). Terminating the subprocess lead to not saving the footer. So i used the win32com approach.

b) Regarding the TCP/IP client, it is pretty simple so far, and only implements starting and stopping and waiting for the confirmation from LabRecorder. How is the protocol to change the filename? Couldn't find it in https://github.com/labstreaminglayer/App-LabRecorder/blob/rcs/tcpinterface.cpp

For completeness: Here https://gist.github.com/agricolab/47d3126d9f150b6584d6ec8c7bc791e7 is the gist with both implementations. I tested them both using the python example streams (Fake EEG and Markers) and inspected the resulting xdf with XDFBrowser.

@tstenner
Copy link
Contributor

I guess i might have to get a compilation workflow set up though, or rely on you handing me over the binaries.

The CI should take care of that, building labrecorder takes about a minute.

a) subprocess.Popen was actually my first approach. But i could not find a way to send keystroke events like {Enter} to close the process gracefully.

That answer's highly misleading, see https://stackoverflow.com/a/32570656 for an example. At least on my PC, p = Popen(['./test'],stdout=PIPE, stdin=PIPE, stderr=PIPE); p.communicate(b'\n') lets the process think enter was pressed.

Terminating the subprocess lead to not saving the footer.

Good catch, I've opened that in #8

How is the protocol to change the filename?

You're right, I thought I'd already implemented that but I think there should be better ways to do this (e.g. with templates with settable variables).

@agricolab
Copy link
Contributor Author

Oh boy, you're right: I did p.stdin.write('b\n') but did not p.stdin.flush(). Stupid. Cool beans, anyways, that means the CLI interface is platform independent now, too. Updated the gist accordingly.

@cboulay
Copy link
Contributor

cboulay commented Jul 30, 2019

Sorry for hijacking. I, too, will soon be interested in minimizing things-that-need-to-be-clicked. What is the latest/best version of Remote LabRecorder?

I noticed that tcpinterface.cpp is in master but empty. The one in the rcs branch seems to be missing features that @agricolab is already using, so it exists somewhere, I guess.

@tstenner
Copy link
Contributor

tstenner commented Aug 2, 2019

I had started a prototype Qt Signals, but they are one-way only so it's practically impossible to get any feedback to commands and I haven't found a better solution yet. For a command line usage, the CLI recorder with the unintended remote control @agricolab found should be your best bet.

@agricolab
Copy link
Contributor Author

just for reference, my most recent version currently lives at https://github.com/pyreiz/pyliesl/blob/master/liesl/files/labrecorder/cli_wrapper.py

@cboulay
Copy link
Contributor

cboulay commented Oct 2, 2019

@Doug1983 put some work into making the GUI-version of RCS implementation more useful. That's now been merged into master (see #19). It's not perfect but it does the job for us and allows us to control LabRecorder from Unity.

As discussed previously, we currently have no way of knowing if the commands sent over RCS were successful. I think if someone wanted to do a Python wrapper for this then they might check names of running processes and check if the prescribed filename exists.

I suppose we should create some docs demonstrating how to use this from C#, Python, and Matlab. Wiki? README? Something else?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants