GlovePie replacement ?

[brantlew]

It seems like the topic of GlovePie and Carl Kenner have been popping up a lot the last few days so this is a good opportunity to discuss the possibility of a replacement for GlovePie. Now I think Carl is a talented developer and GlovePie is a phenomenal tool and pretty much everyone in this forum uses it in some form or fashion. But from what I gather Carl seems like a bit of a loose cannon. He chooses to exclude support for particular devices for trivial and arbitrary reasons, and he uses GlovePie to push his personal agenda and as leverage against his perceived enemies. In the meantime - the rest of us in the community are held hostage to his whims. At any time, GlovePie support for a device can be dropped - and not for technical or legal reasons but for simple vendetta. Now it's his software and as creator I think he has the right to do whatever he wants with it. But that doesn't mean that we have to accept it. There are a lot of good developers out there and (frankly) GlovePie ain't exactly rocket science - just a script parser and an accumulation of "mostly" documented hardware APIs. So an open-source, community driven replacement for GlovePie is a very real possibility and would help remove all the uncertainty associated with the product.

So how many of you think this is a good idea or are the majority of users satisfied with GlovePie? (Disclaimer: I've been particularly burned by GlovePie because I use a Vuzix HMD and have had to implement four device interfaces because of it)

Which devices would absolutely need to be included for a viable replacement?

Which devices have been left out of GlovePie that you would like to see supported?

What software features does GlovePie lack that would be handy?

Is there a better design or usage model than the one GlovePie implements? (ie. event registration versus polling)

How much code exists out there that could be included in an open-source project?

Does anyone actually have the skill, inclination, and time to partake in a project like this?

Any other thoughts or opinions?

[CyberVillain]

Sounds like a fun project, if the target platform is .NET I can contribute.
Python has parsers for C#

edit: for a first version I think mouse emulation (With DirectX relative X / Y emulation), PPJoy, TrackIR, and Freetrack emulation is fine (For mee atlest). But lots of people probablt want WiiMote, Kinect, etc... Would be nice with a generic interface too, so anyone can implement an input plugin for it...

[WiredEarp]

I think I've heard something about 'OpenPIE' already somewhere...?

IMHO, the most important thing would be the base parser, and a framework that supports easy creation of plugins. That way, there could be a parser, and a few base plugins (trackir, ppjoy, freetrack) and people could develop their own ones and access their plugins objects using the parser.

That way, people can develop plugin objects for their different needs, and then share them with the wider community, without having to rerelease the base software, or debate its inclusion in an open source system.

[brantlew]

From what I've seen, OpenPIE is a stagnant project that currently only supports the Wiimote. I haven't looked at the source but probably not a whole lot there to build on. The script parser might be an interesting read though.

I agree that the most crucial part of the project is a well thought out script engine. The modular design is a good idea and should be built int to the script engine from the start. I would extend that idea even further though. It would be great if it was released as a DLL library. The actual "PIE" app would just run a script parser, GUI, and call into the PIE.dll Other applications could also call the PIE.dll as well though. That way if I write my own device, I can easily include native PIE emulation without having to run a separate PIE instance.

[CyberVillain]

From what I've seen, OpenPIE is a stagnant project that currently only supports the Wiimote. I haven't looked at the source but probably not a whole lot there to build on. The script parser might be an interesting read though.

I agree that the most crucial part of the project is a well thought out script engine. The modular design is a good idea and should be built int to the script engine from the start. I would extend that idea even further though. It would be great if it was released as a DLL library. The actual "PIE" app would just run a script parser, GUI, and call into the PIE.dll Other applications could also call the PIE.dll as well though. That way if I write my own device, I can easily include native PIE emulation without having to run a separate PIE instance.

Thats the way I always write my GUI's A backend assembly that a frontend WPF client references

[WiredEarp]

I think you are correct, a DLL format would be the best, as you can expose all the PIE capabilities to anything easily, and its not much more difficult to do. The main GUI can just call the routines from the DLL itself. Also, using a DLL is probably the easiest way to implement the plugins.

One idea might be to make it use VRPN, the VR open peripheral interface standard. That way, you'd have a system that works with many different systems already, and anything new written for VRPN is automatically useable by PIE. In fact, VRPN could make the whole point of a PIE replacement rather unnecessary, you could just write VRPN objects to do the mouse and keyboard etc (if they dont already exist) and then use any scripting language you want to tie it all together. This might be worth considering, as doing it all yourself is a big undertaking...

[CyberVillain]

One of the biggest obstacles is finding a flexible script parser engine that supports code completion and that lets you add custom keywords to the code completion dictionary other then the ones that belong to the script language (We want code completion for our input / output plugins, something like Mouse.X = 5 should be code completed)

[brantlew]

One idea might be to make it use VRPN, the VR open peripheral interface standard

That's a really good find. I skimmed the documentation but the details of how it all fits together are still a bit vague to me. Seems like you would still need to add a piece to perform device translation and emulation - maybe a modified VRPN Server or some kind of client add-on. It's definitely worth investigating - even if it was just used as a generic interface for non-native or existing VRPN devices (sort of like a better version of the OSC interface in GlovePIE)

[cybereality]

I would be interested in this as well. I am actually in the research stages for a 3D driver of sorts, but with a big emphasis on support for exotic peripherals. Initially I wanted to make it a commercial project, but there are some roadblocks to this. Mainly that some libraries (ie Kinect) are non-commercial only and others are GPLed. So an open source project may make more sense.

My idea was that each peripheral would have its own DLL which would implement a standard interface. For example, there could be generic specifications of the devices abilities which would use a standard set of components. For example, a set of floating-point 3D unit vectors could probably model any N-Degrees of Freedom device. Or course there would be mouse, keyboard, and joystick emulation. I would also like force-feedback to be a big part of this. There are existing device that could benefit (Falcon, 3rd Space Vest) and also the opportunity for people to wire up their own homebrew equipment and have it be supported.

So I am thinking a little broader than just headtrackers and wiimotes. I want to see custom ambilight setups made possible with the driver. For example, the scripting language could expose the raw back-buffer for the game so that a coder can write their own algorithm that would determine the color to illuminate the walls with. Maybe the driver could determine a relative velocity of the player, so that a racing game could have fans blow in the appropriate direction. Or in an FPS game that software would reveal what direction the character was moving so that an omni-direction treadmill can go the opposite direction. Maybe this is too much, I don't know. But that is what I was thinking.

Also, I was going to call this driver ioVR. Anyone like that name?

[brantlew]

Wow CyBer, that's a pretty big set of features! I'm having trouble envisioning how all of it fits together into a cohesive package, but you have been thinking about this stuff a lot longer than the rest of us. It sounds like you are aiming for the engine to have some form of built in scene interpretation. So by your example you could register a fan as some type of "enviromental" device and a controller as a type of "character motion" device. Then the engine would automatically run the fans at the correct speed and direction based on the computed character motion without any programmatic scripting. Or something like that?

It's a very ambitious approach. My concern is that it puts a lot of responsibility on the programmers to foresee and prepare so many scenarios and combinations of hardware, versus the GlovePie model that just presents a powerful yet concise scripting language and asks the user to handle these unique scenarios.

[cybereality]

No, it would still be scripting based. There's nothing automatic. But there may be a front-end where you can just connect inputs and outputs. At the basic level it could be like MotionInJoy or as advanced as a visual scripting editor. Still have a lot of stuff to work out with the design. I am trying to focus on just the stereo 3D aspect of it now, maybe it could be a separate project that just interfaces well. But some of the stuff I want to do will require tight integration of DirectX and the input devices. For example, independent gun and head tracking. So, yes, this is the early stages but I am very much interested.

[CyberVillain]

What about using LUA? I do not know if there is any IDE for LUA that can be integrated into a program like a DLL, but i will research it

edit: with a bit of work you can maybe integrate LuaEdit into a C# program

http://sourceforge.net/projects/luaedit/" onclick="window.open(this.href);return false;

[cybereality]

Yeah, LUA would be a good choice. I actually wanted to work on a LUA editor for another project of mine, this would be a great opportunity to experiment with things. Too much to do and I'm just SOOOOO busy. Arrrrg....

[brantlew]

LUA sounds reasonable.

The more I think about it the more a layered approach to this project makes sense. At the core, the real assets are all the hardware interface modules. Each device has it's own idiosyncrasies and tricks to interface and emulate it and having all of that r&d packaged into simple functions is invaluable. So for me the core module is simply the collection of device interface/emulation functions. It has been suggested that each device should have it's own DLL, but I think to simplify debugging, packaging, and support it would be better to aggregate them. That way you just officially track and support a single module and version number without having all these separately versioned DLLs running around. You could still provide a plug mechanism (DLL or comm channel) to extend other devices before they became part of the official release.

On top of that core you build other types of apps. Of course one of them would be the GlovePie alternative consisting of a polling script parser. Another might be more complex - along the lines of CyBer's ideas. Additionally you could provide emulation for novel devices by just linking to the core library. For example, I could easily include native XBox 360 emulation to my FriiSpace project.

Edit: So far no names have just jumped up and grabbed me. My first thoughts were something really prosaic like PIE or Device Interface Bridge (DIB) or Device Interface and Emulation Library (DIEL). Boring but accurate. Recently I've been attracted to something less accurate but more quirky and catchy -- "Oliver" (which is sort of a homophone of "all VR")

[WiredEarp]

The layered approach sounds good. I guess if you rolled everything into the initial release but supported extension by dll, that would be fine. Although, I don't see why you wouldn't just ship the thing with all currently known DLL's and keep the plug in architecture nice and simple?

Thinking about the whole thing however, the whole GUI part of GlovePIE is really of little use to me (and most of us probably). If I was designing a new system to do a similar thing, I'd probably just keep it at a library level and use an existing scripting language to glue it all together. That saves you a whole lot of GUI and scripting coding, and lets you leverage existing coding solutions. GlovePIE seems to have been designed to let non-coders do stuff, and thats good, but personally I know how to code and I dont really see the point in redoing stuff in GlovePIE script when I can just call the libraries directly, especially since I then get full debugging support etc from whatever IDE I am coding in.

[bobv5]

Gaaaaaaaahhhhhhh!!!!!!!

I'm pretty sure I'm not the only guy here that sucks at programming. I am slowly learning, but could really do without that sort of hassle when I'm trying to play. I suspect a lot of the guys doing hardware stuf feel the same way.

Otherwise I have been staying out of this one as I have litle to add, but it is sounding good so far.

EDIT- I always use the text entry part of glovepie, which I can cope with, but I really don't want to be installing and learning a new IDE just for a glovepie replacement. If I had to I probably would, but many wouldn't.

[WiredEarp]

Fair enough, although GlovePIE IS coding really, just a different language and IDE...

[bobv5]

heh, see the edit...

[CyberVillain]

Ive been researching Lua, I've used it before so I know its VERY easy to integrate to a C# app (We still havent decidec which language to use). But I wanted to go furher and see if there are any ready to go editor that you can just integrate to your own GUI. No luck there, so in that case people would get a lesser experience then with GlovePIE, first time I did a GlovePIE script I could do the whole thing without any reading up first thanks to the code completion, so I think its an important feature.

What we could do is implement our own code completion only for the input output plugins, a bit of work, but could work (I havent checked but I think that GlovePIE's code completion i limeted to that). Also i think a poll system is easier then a event driven one, both for development and for the novice to use...

[cybereality]

The best thing would be to have the code editor integrated into the program like in GlovePIE. Using a 3rd party IDE makes sense for developers, but does isolate non-coders. It also means the driver will have external dependencies that may change/update and then no longer work anymore. So a custom editor may be the best solution. Of course, code completion is a must have feature. I think the event driven model is going to be the better one, but its probably easier for everyone to use polling. Once we get to that point we should do some tests to see if there is a huge performance difference. And we could support both designs and let users use the one they feel more comfortable with.

[brantlew]

Another reason to keep the polling paradigm would be to make it compatible with existing GlovePie scripts. An event driven model would necessitate a substantially different scripting style. Depending on how sophisticated your script "compiler" is, you can run everything underneath using an event driven model and still expose it to the user as though they are polling. Best of both worlds.

As far as languages go. I think the best choice for the device interface modules is C. That's pretty much the common denominator for hardware interfacing in general. Most code examples are in C and there a lot of devices that only have C API's. I know that you can access C libraries from C# but it's sometimes difficult to recast all the relevant structures into their C# equivalents. Also with straight C, there is the possibility of cross platform support.

For the script parser/GUI, C# is a good choice if you decide to only support Windows. A lot less bugs to worry about and believe me - creating GUI's is twice as easy in .Net than Win32 or MFC. If you want cross platform support then Java is a good choice.

While I'm on the topic, how many Mac and Linux users are there out there that would like to use a GlovePie tool? Is cross-platform support an important feature?

[CyberVillain]

You can do the wrapping in the lib that needs it and the public interfaces can be .NET
I've used .NET both on Android and Linux, not on a apple product. But I do not think a apple user even knows what a HMD or head tracking is

[pierreye]

If we use the program just for gaming, I think supporting Mac or Linux would not be important. I would prefer an easy to program development tools and most of us can contribute. I'm more of a Windows guy.

[CyberVillain]

I found this

AvalonEdit

its a WPF control, looks like it can support Lua

[CyberVillain]

OK guys, heres a little round up on my take at this.

The software should consist of 3 main Assemblies

1) light weight assembly only containing interfaces and datastructures for the Core and custom plugins
2) Main logic assembly, here we will house the core plugins and also manage the Lua script engine, etc
3) WPF GUI (I think we should use Caliburn Micro which is a excellent MVVM API for WPF, WP7, SL) A very simple GUI with a editor maybe use AvalonEdit that I mentioned above. I would also like an interface for add and edit curves. A curve can look like this



Then from Lua script you do (Pseudo code not Lua)

Code: Select all

TrackIR.Yaw = CubicSplineCurve("CurveNameChoosenInGUI", Someinput.Yaw)

[cybereality]

If I understand correct, this AvalonEdit is just a text editor with highlighting. We would still be responsible for writing a compiler, right? I want to create something that can be updated on the fly without a long compiling step. So you could just edit the script live and when you save it, it automatically changes. I believe GlovePIE allows this kind of editing and testing. That way you could have a game open in a window and experiment. It would be too annoying to have to edit, save, compile and then reload the driver and re-open the game.

Also, I don't think there is much point in cross-platform for this. Who are we kidding, all the games are on PC.

[brantlew]

These scripts are usually only a few dozen lines so compilation would be lightening fast on run. Not a separate step - more like a JIT compiler. GlovePie does something similar or at least it does a syntax check on run. Also "compile" is a pretty strong word. We're not talking about going to machine code. Just potentially setting up some event handlers. So for example if your script checks the W key-press, you could implement it straight and actually poll the W key state on every loop or the "compiler" could just setup a callback function and only run the "W" code when it got a signal. Or something like that to avoid excessive and expensive system calls. Anyway it's not a necessity for a version 1.0, just an optimization that could be done at some point.

Yeah Cyber, I figured Windows PC is the only real target - but sometimes these Linux guys lurk in the corners.

[PalmerTech]

I have nothing constructive to add to this software discussion, other than to say that you guys are smart as hell. Good luck, this sounds great!

[brantlew]

Not really. Code geeks just compete to see who can throw the most acronyms into one sentence.

[CyberVillain]

AvalonEdit has nothing todo with the Lua runtime, thats a different API. As you said it's only a highlighting text editor and give you some help with code completion (We still have to supply the database, so we have to do with the input/output objects and their methods). The Lua engine can take scripts at runtime, compile them and run them. No need for recompiling the .NET software....

AvalonEdit need a xshd file for LUA to be able to highlighted corretly, I didnt find one online, so we have to make one ourself.. We could base it off the C one

[CyberVillain]

Not really. Code geeks just compete to see who can throw the most acronyms into one sentence.

Do not include me in that!

[cybereality]

Personally, I'd like to use C++ for this. Mainly because I have invested a lot of time recently to learning it (reading the 1500 page tome that is C++ Primer Plus). But also because most device APIs are written for C++ (or at least C). I don't have as much experience (or much at all really) with C#, though if it really is a better fit for this project then I am open to learning it.

[WiredEarp]

Personally, I like C++ myself. Pretty much anything you need to do in C, can be done in C++. However, if the architecture is correct, you could let people develop additional interfaces in lots of different languages as long as they can compile to a DLL.

For GUI stuff you'd probably be better off with C#, VB.NET, or whatever else you prefer, simply because its quicker and easier to develop a gui using these systems.

I wouldn't consider trying for cross platform support yet, especially for an application that basically has custom drivers. Differences between the way different OS's do things mean it wouldn't be 100% cross compatible without extra work anyway.

CyberReality, if you can handle C++, you'll pick up C# very easily. A lot like C++ without writing headers.

I believe PPJoy doesn't work on 64 bit windows due to requiring a hardware driver certificate. I think I needed to use 'test' mode to get it going. However, I was reading a security site recently and noticed that there have been several trojans/viruses recently that have used stolen keys to sign their own drivers so users don't notice them being installed. I was wondering if we could just piggyback on one of these and use it to install on 64 bit wihout needing test mode?

[brantlew]

I concur that C++ is the way to go for the device interfaces. The C++ syntax and compilers are much easier to use. When I talk about programming in C, I am usually just talking about a style of programming that uses lots of top-to-bottom function calls instead of big convoluted class infrastructures. But I always use C++ syntax rules. When writing hardware interfaces you tend to naturally gravitate toward the simpler functional style anyway just because everything you link with tends to be implemented that way.

As far as Windows GUI programming goes - I spent 5 years working in MFC (C++) at one job and was quite adept at it (near guru level), but I would never go back to it after using .Net. And of course C# is the poster child for .Net so it is a logical choice.

[CyberVillain]

Yeah, I think the main framework should be in C# because its so nice to have that in a managed langauge.
Except for the texteditor I think the C# project will be very light, maybe a few of the input / output plugins will be written in it, but for some cases we will have to invoke C++ code, thats very easy todo from C# so I still think we should go for C# interfaces and plugins and that the plugins that need it invoke CPP code...

A managed language is so much nicer to work with when it comes to a software like this, much easier to keep it clean and tidy... And dont get me started on WPF, together with a MVVM framework like Caliburn its a dream to work with

[bobv5]

Trouble with .net is when it sends me off to install a massive framework to run a tiny app. Very annoying.

[ERP]

The issue with .net is the cost of managed to unmanaged transitions, if you're expecting client software to be largely C++ then I'd write it in C++, if you're expecting them to be .net it probably doesn't much matter.

[brantlew]

Trouble with .net is when it sends me off to install a massive framework to run a tiny app. Very annoying.

True. Microsoft really needs to settle with a stable .NET version for a few years - or better backwards compatibility. You would think a brand new Windows 7 install would not require any .Net runtime installs but you would be wrong. Unfortunately with all the dramatic GUI changes in Windows 8, it probably won't get better anytime soon. Reminds me of DirectX. It took them 9 1/2 versions to finally stabilize that API.

[bobv5]

Yeah Cyber, I figured Windows PC is the only real target - but sometimes these Linux guys lurk in the corners.

I actually do prefer linux, but its no good for games. A true linux geek wouldn't want this anyway, VR on linux would probably be SERIOUS VR, and the source code would be available to add support right into the app, no hackish glovepie thing needed.

[Johnny-Mnemonic]

...Unfortunately with all the dramatic GUI changes in Windows 8, it probably won't get better anytime soon. Reminds me of DirectX. It took them 9 1/2 versions to finally stabilize that API.

With all the dramatic changes in Win8 GUI, Microsoft will abandon .NET, so there's no point to code something for it anyway.