Standalone application

[toncho11]

Hi,

I would like to code a standalone application that starts OpenVibe and executes a scenario.

Do you have such demo? Where should I look into?

Which C++ classes do I have to use? I need a player, a scheduler?

I do not need any UI. I need stripped down code that focuses only on starting and executing a scenario.

Cheers,
Anton

[yrenard]

Dear Anton,

please see the following blog post : Starting the designer from a console.

Hope this helps,
Yann

[toncho11]

Hi,

My question was more form software development perspective.

I tried for example to decouple the Designer from using GTK and simply leave the functionality that

- imports a scenario
- creates a player
- plays the scenario

So far it turned to be very hard as I haven't still figured the API.

I just need a sample in C++ where scenario is imported and then played with the OpenVibe's "Player" C++ class.

This is for my own consumption, but I think it will be useful for every one.

Thanks,
Anton

[yrenard]

Dear Anton,

the designer already does that, just use --no-gui flag and a well prepared Player Controller box and you're done ; hard to make it easier.

Regards,
Yann

[toncho11]

Dear Yann,

I want to completely get rid of the GTK dependencies.

When using the "--no-gui" the GTK is still there and the only difference is that Window.Show() (or something like that) is not executed. I am actually trying to execute the designer as a Dll from another C++ application. It is like I want to process something with the designer and then stop it. Imagine I want to start the designer, train a classifier and close the designer and do all that programatically.

[yrenard]

Dear Anton,

the kernel itself relies on GTK, you can't get rid of it

Really, have you read the blog post I pointed out ? From a standalone application (whatever app you want actually), if you want to train a classifier, just run the openvibe designer (if you use C or C++, system is a good command to start with for instance) with --no-gui flag, then use the player controller to stop the scenario when you need it - it will silently close the invisible designer. Based on what you ask, this solves your problem ; if it does not, then give us more details about the problem.

It takes some time to accurately support the problems users are facing and I proposed a solution to what you stated as your problem, please give it a try.

Regards,
Yann

[toncho11]

Thank you for your patience indeed

I am kind of disappointed because of the hard-coded GTK dependency.

So one can send commands to the PlayerBox through the keyboard simulator or even using VRPN button client which connects to an external application.

[yrenard]

Dear Anton,

sorry for the hard dependency to GTK, this has been a long discussed choice with Vincent something like 3/4 years back from now. Providing an abstraction of such a toolkit is a huge effort and was not realistic based on the man power we had back then. Ogre is a different approach, only the kernel relies on Ogre which is totally hidden from the 3D boxes.

In order to trigger the stopping of the scenario, you could also use the Lua Stimulator or the output of the classifier trainer / spatial filter trainers for instance, so you don't have to stop it manually, it's totally automatic !

Regards,
Yann

[toncho11]

I had much bigger idea indeed about the designer.

If the GUI could be decoupled then the designer can be compiled in VC++ in managed mode. Then managed C# wrappers will be written for the main classes and then OpenVibe will have a managed API.

For example my Adastra application will be able to execute OpenVibe internally by instantiating a class and calling the "go" method.
I tried all this, but it did not work in the end. If the UI is decoupled then I will be able to trace the problem much more easily.

Currently the UI dlls must be loaded although no UI is required. In the end some of them do not load and this results in a exception.