Remote Control

[like-a-bause]

To be truly useable an Application for remote Controlling the App would be great. Have you looked into that? I would suggest doing it over OSC and mirror the scene on the Remote Controlling device.

[kr15h]

Yes, I've thought about that. Actually my intention is to make a web interface for this one so it can be controlled from any touch-device over local network. That would involve launching a kind-of web-server instance from the app. And I did that when I made the initial prototypes - the mapping app had OSC listeners, Apache with a PHP module was started on the Pi in parallel and OSC messages were sent to the app from the web interface. Right now I'm kind of exploring Single Page Application ways as a part of a commissioned project. It seems that I'll be using riot.js as it is very lightweight. My intention is to get a bit more comfortable with the MVP ways and then use that knowledge to start building the web interface side for the PiMapper.

[silantnode]

Maybe time can be saved if ofxPiMapper is combined with this other open source project...

http://pocketvj.com/

I have a project coming up and would love to use both tools together. I have not spent time tinkering with it yet, so maybe this is already possible?

[kr15h]

It might be possible. I doubt that the creators of the PocketVJ use something else instead Raspbian. And I think it is possible but there will be a bit of tinkering involved - you will need to compile this one to get it work on the PocketVJ.

[kr15h]

So definitely OSC API would be the thing to add at this point.

[like-a-bause]

OSC would be my choise for controll data (Set Vertex Coords, Tex Coords). Since this is build on top of UDP, I would do the Content (Image, Video) upload on something TCP based. You can send blobs thorugh OSC but without error correction it would be possible that a bit flips and the files get corrupted. A good way would be a seperate Api for uploading video/image to the data folder and watching the folder with ofxIO.

[kr15h]

Yes, ofxIO seems really nice, especially the event thing that you can get notifier whenever a new file has appeared and that file can be added to sources list in the PiMapper. Today I also thought of something like a file browser there, but maybe that's an UI overkill.

So the question here would be where do we begin? I think that the OSC receiver has to be a new class:

ofxSurfaceManagerOsc()

It would have a pointer to the ofxSurfaceManager() just like the ofxSurfaceManagerGui(). It would do things with the ofxSurfaceManager() according to OSC messages received.

We should define the OSC address space that we would use then. I think we should start with something like /ofxPiMapper and then have commands for switching modes and adjusting some global stuff, like /ofxPiMapper/mode/setMode and pass the view name as string. Then for doing something with the specific views we would use /ofxPiMapper/mode/projectionMapping/selectSurface. I will add to this a bit later, but maybe someone has a better idea?

[magdesign]

I'm trying to remote control with xdotool. This would be a very simple solution to control PiMapper over a Webserver (already wrote some simple interface). While testing it works for all sorts of programms exept for the ofxPiMapper, it seems that openframeworks loads the keyboard native from the usb, can you switch this? Might it be possible to listen to systems keyboard?

Maybe someone can give me a hint. Update: I think I have to emulate a fake keyboard in /dev/input which will be loaded by PiMapper when no real keyboard is connected

[magdesign]

Solved: I finally created a fake keyboard with the uinput command and the help of his tools: http://www.fsays.eu/Blogging/Blog/Details/23 with fsayskeyboard its now possible to send remote keyboard commands. Next step will be the mouse.....

[kr15h]

The trick I want to do here is to create an OSC interface that would allow to send messages from other devices in the same network.

[kr15h]

And before I do that, I want to make use of the Command Design Pattern to enable undo support in future versions as well. If all of the supported commands would be as separate classes - it would be much easier to create the OSC interface as a separate module.

[magdesign]

OSC sounds great, I've now finished a simple control overlay via html/php. https://github.com/magdesign/PocketVJ-CP-v2 Thanks for your amazing work, looking forward for new features...

[kr15h]

I am thinking towards creating a TCP-based API for this.

[reno-]

Hi, I just tried PiMapper and I love it ! I would be perfect to remote it through OSC, Artnet (control from a lighting board), or TCP.

Maybe a python API could solve the issue as it might be simple to create differents protocols implementations with a python API? just my 2 cents…

[magdesign]

TCP already works emulating an usb keyboard... its a bit of a hack, but it works.... https://github.com/magdesign/PocketVJ-CP-v3

[magdesign]

Working on new approaches for remote control PiMapper using:

• vnc screensharing (very slow and laggy)
• nomachine remote desktop
• virtualgl
• gstreamer (with this, mouse and keyboard emulation is still an issue)
• uv4l (limited to 640x480 for the moment)
• x11 forwarding via ssh (ssh -X pi@ip.add.re.ss, then type: lxsession)

The nomachine approach looks promising, for the moment i'm struggling rendering PiMapper's output since its not rendered into the x-window system, so looking for a solution to grab the (i guess its) OpenGL_ES OpenVG. The thought behind this is, when you map a facade, you might loose the mouse, so you would still see it on your laptop.. I know that when using an x-window system we loose a bit of performance... Anyone any idea on this?

[kr15h]

The way I want to go is opening a TCP API.

[kr15h]

I am close. Right now I am decoupling the keyboard shortcuts. Basically I am almost finished with having all the shortcuts as ofxPiMapper class methods. One would then add a TCP layer on top of it and it would be possible to create two example applications:

1. TCP sender (the controller on one's laptop)
2. TCP receiver (running on a raspi)

One could see the same on the laptop and it would directly influence things happening on raspi.

[magdesign]

cool. That means I stop spending more time on my screenshare "hacks"...

[kr15h]

Yes.

[a0n]

@kr15h would you like to put your current satus in a branch?

[kr15h]

I have it ready actually. I have to add it as an example. Currently a too busy with organizing an event. Next week will add it.

[kr15h]

For the ones involved in this discussion, I finally added remote control capability as examples. There are two of those.

• example_remote-server
• example-remote-client

I decided to leave them as examples rather than integrating TCP code into ofxPiMapper core, which I would prefer focused on the primary task - projection mapping. For the bundled version (the iso file) I would make it so that one can connect with the remote from a remote PC.

I will add basic instructions on how to use this as soon as I can.

[magdesign]

Amazing! Really looking forward to test this. So I have to compile a client on my computer to control the PiMapper on the RPi, right? Ah, I just found the readme. Thanks for that, i will report back after testing.

[kr15h]

You have to compile the server example on RPi as well @magdesign

[kr15h]

But when I pull together the .img file, the TCP server will be there.

[controla]

This is working perfectly, testing it right now. Had to mess with xrandr panning in the client to simulate the same resolution as the pi. All works so far except for the arrow keys and shift combinations. Is there a way to enable them or replace the binding?

[kr15h]

Have to look into that. There are many options there. Have to test and decide what would be best. The problem with arrows and shift is that they are defined as OF constants.

[kr15h]

OK, since the remote control option is there, I will close this now and open up bug issues for each improvement we want to make.