2

I have been tasked with programming a GUI for the Adaptive Use Musical Instrument project (AUMI). The GUI is a musical creation tool for people with limited mobility. The current GUI takes data from a video camera, displays it on screen, allows the user to select a point to track (using openCV) and uses this data to cue midi notes/audio samples.

A workable implementation currently exists in MaxMSP, but it has become slow, difficult to manage, buggy and cross-incompatible over time (and size). I will be re-implementing it in a different framework, though I have not yet decided on which. Processing, OpenFrameworks, Juce and Qt have all been brought up as possibilities.

Requirements:

  • Final GUI must work on Windows and Mac.
  • Computer vision should run as smoothly as possible, even on low end machines (we're just doing point tracking now, though hopefully fancier stuff in the future).
  • The GUI must require basically NO technical expertise from its users, this is used in schools mostly. I realize this depends a lot on design, but I also don't want a build with a million files that the user needs to navigate.

Thoughts? Basically I'm trying to find the best balance of programming time (I don't have a ton) and final functionality. MaxMSP was great to get a prototype up and running, but we need something more scalable. It would be really nice to start in the right place.

Aaron Krajeski
  • 757
  • 5
  • 18
  • what have you done, in the end? – nkint Apr 03 '14 at 10:22
  • OpenFrameworks! Processing turned out to be too heavy and I didn't really try the others (no offense Roozbeh!). The CV and cross-compatibility were very easy, though the UI stuff is a bit cumbersome. Still working on it (they're no longer paying me, so it's a labor of love). Will link here if/when I finish. – Aaron Krajeski Apr 04 '14 at 12:17

3 Answers3

4

I have used Qt. It's really clean, manageable and fast. By using Qt Creator you would be able to create user interface very fast.

Linking openCV on Windows/Mac environment would not be a problem for you. Qt also let you have different linking rules for Windows and Mac, which would make it even easier for you. For threading and networking, you could use its internal classes. Then you would not need to link to different libraries on Win32 and Mac OS.

Recently they added Android support too. And they had Linux support before. So, you app would works on Win32/Mac/Linux/Android and probably on iOS soon. I guess that would be huge benefit.

I have also used wxWidgets with an OpenCV project couple years ago. I prefer Qt now.

László Papp
  • 51,870
  • 39
  • 111
  • 135
Roozbeh Zabihollahi
  • 7,207
  • 45
  • 39
1

openFrameworks still doesn't have an "official" comprehensive GUI solution but several good cross-platform / cross-device solutions are available via addons. Currently the most popular one is https://github.com/rezaali/ofxUI. You can explore other GUI options by checking out http://ofxaddons.com/ and filtering by GUI. As of openFrameworks 0.8.0 we are using GLFW 3 as our Desktop Windowing system (replacing GLUT) which gives us much better keyboard and input event handling. This is great news for the openFramework GUIs.

While it is not impossible to use Qt with openFrameworks (see this forum post for a discussion), some of the ofxAddon-based GUIs will enable much quicker integration with openFrameworks, which is important if you don't have a lot of extra coding time and you need easy access to OpenCV, and the world of easy-to-use addons available for openFrameworks. One final tip -- if you choose to go the openFrameworks route, I highly recommend https://github.com/kylemcdonald/ofxCv. It is an alternative to openFramework's built-in OpenCV support and is full of helpful examples. Good luck!

bakercp
  • 924
  • 7
  • 12
0

After intensive use of both open frameworks and Qt, I would say open frameworks. Much more easy to interface with sound software, and with OpenGL.

Even if qt has a big and nice integration with OpenGL there are changes on qt5, still some problem - as far as I have tried it - with qml, integration between OpenGL and OpenCV has to be done manually transferring a opencv image to a OpenGL texture, etc.. I can say you because I have tried to implement something similar in Qt and if I could go back I would choose openframeworks for sure.

It is doable, of course, with Qt. But openframeworks is born to do those kind of tool. Qt is something more. See bakercp answer for details on add-ons.

Community
  • 1
  • 1
nkint
  • 11,513
  • 31
  • 103
  • 174