About GUI frameworks…

Mar 28, 2013 at 5:17pm

About GUI frameworks…

Hi,

I would like to implement a GUI external without the use of the graphic routines from the MaxSDK. The purpose is to reuse the same code for a Pure Date version ; i have no idea which Framework/Library is best suited for that (Juce, Qt, openframeworks/cairo…) ; the best is a cross-platform one with a permissive licence.

I know that it is a bit vague ; but to help me to make the good choice i’m looking for success examples, or advices, links, thoughts are welcomed also. Thanks

#67400
Mar 28, 2013 at 7:31pm

Out of curiosity, what’s wrong with jgraphics? It’s cross platform as far as Max is concerned.

#242463
Mar 29, 2013 at 6:54am

Hi,

The ability to create my own windows (for instance with dblclick on my object) is something i need. Except that nothing is wrong “as far as Max is concerned” ; but MaxMSP is not the only concerned.

I plan to use the same GUI for Pure Data also. The best should be a C++ framework with score notation but for now i found nothing really attractive. I don’t want to sticked to MaxSDK. I’m more and more seduced by something like “libpd”. All my work is a prototype and i’m not an experienced developper, i did a bunch of design errors, a day surely i will have to rewrite everything from scratch. But until those day i want to be able to reuse my work in various situations specially because i’m not really seduced by the evolution of Max/MSP since Max 5.

#242464
Mar 29, 2013 at 9:30pm

Hi,

I believe that if you really want to build a GUI object which behaves as a max/pd external
with inlet, outlets, standart max/pd functions, etc. the possibilities are very much restricted.

http://cycling74.com/forums/topic.php?id=43103

But if you’re fine with an “external” which only exists in a window/view without having all standart max functions would at least open the possibility to use every c/c++/obj-c framework you like.
The question might be how you want to operate on data and how you can embed this type into your different environments.
In general I think it is a good idea to decouple the dependencies from the standart Max API to give you a free choice.

At this moment I’m working on how to combine jpatcherviews and cocoaviews(I mean views with non max GUI) best. (Don’t know if this will lead to anything.)
However I can already open patcherwindows & cocoawindows from code and stick them to a “main” window. Like this(removing borders and titlebar) they pretty much behave like a bpatcher but I can put anything I like into the window, using any framework I Iike. (Of course it does not have the standart max functions, inlets outlets, etc.)

My idea is the following: You need a space/frame/view/window/whatever of which you know it can exist, be created in the differerent environments you want to use it in. So lets assume you choose s.th like a window created with c++, in which your GUI lives.
If you write a GUI being able to work in this window and the way the data is edited differs between your environments you could use s.th like different controller classes which do the actual data editing while the GUI-Editor is sending what had klicked, moved, done in the Editor. You could define a list of methods which your GUI controller has to implement. So s.th like GUI(“button has been clicked”)->max controller do the data manipulation for max. Or GUI(“button has been clicked”)->pd controller do the data manipulation for pd, etc. You might have to think about if there’s something specific how the data is send from your controller to the environment or the other way around.

I was lately looking at some frameworks and found cinder very attractive.
http://libcinder.org/ I don’t know about a framework with scorenotation. I think the frameworks are all kept more general.
Maybe Andrea can help you with an idea which frameworks could be used. http://cycling74.com/toolbox/bach-automated-composers-helper/

HTH

#242465
Mar 30, 2013 at 7:11am

Hi,

thanks for taking the time to respond.

1. I read few threads in the forum and it seems that dynamic linking the Juce engine of Max/MSP is not possible (Max/MSP is statically linked), whereas you can use Juce freely in your external if you manage everything. Must be confirmed.

2. Few times ago i did a test (that i posted on this forum) to create a GUI with a NSWindow with objective-C ; but as it is not portable (i want to migrate to GNU/Linux) that’s not an option.

3. My object will be designed in such a way that the core can be controlled remotely by properly sent messages from anything anywhere. Of course i could write various GUI for various platform. But i prefer to avoid it.

4. If i’m not wrong Cinder use Cairo for 2D rendering (like openFrameworks). Cinder does not support GNULinux. So if i need to use such, i prefer to go with openFrameworks.

5. I asked Andrea about the Bach code ( http://cycling74.com/forums/topic.php?id=39295) ; but it’s something closed and secret ;-)

6. FTM seems to use mxj / Java. Correct me if i’m wrong. Lots of objects relative to score notation seems to use Java.

7. I found “Belle Bonne Sage” ( http://bellebonnesage.sourceforge.net/ ). Anybody ?

#242466
Mar 30, 2013 at 8:14am

Hi. Here I am…

Well, yes, the bach source code is closed – although there are no big secrets, and actually we might choose to open it at some point.

Anyway. Everything in bach is done with the Max API. No Cocoa, no Juce, nothing. This has been a pain in the ass sometimes, and we had to give up some things we wanted to do: what we gained was (almost) seamless integration with the Max environment in both Max and Windows, which for the moment is what we really need.

What I can tell you for sure (I tried it) is: it’s not that complicated turning some functionalities of a Max UI object into a Juce component. It is, basically, a matter of:
- decoupling as much as possible your algorithms and data structures from the Max API.
- setting up some intermediate wrappers that will conditionally call Max or Juce functions and methods (for graphics, threading, scheduling, …). Basically, all these systems look the same – including the notion of doing vector-based graphics in an abstract graphic context via a “paint” method…
- conditionally wrapping your object’s method into Max methods or Juce-based C++ methods.

I have no experience with that, but I guess that if you want to do the same with Cocoa, OpenFrameworks or whatever you can follow the same basic guidelines…

hth…
aa

ps: InScore is open source… and it’s just great… have you looked into that? And belle bone sage looks awesome!

#242467
Mar 30, 2013 at 12:00pm

Hi,

1. “…decoupling as much as possible your algorithms and data structures from the Max API.”

Except for object’s life management, I will no more used anything from the MaxSDK ; for now i plan to use C++ STL and Boost containers. But because i found the Juce API so attractive (Property Tree with Undo/Redo manager…), i could use it exclusively.

2. “Everything in bach is done with the Max API.”

Good to know.

3. Currently InScore / GUIDOLib doesn’t convince me ; surely i’m wrong but it doesn’t seem to be maintained continuously ( http://www.grame.fr/offres-de-stages ) ; “Belle Bonne Sage” can use Juce for rendering ; and Juce is daily improved.

Anyway i need to investigate more to make choices. Pros / Cons appreciated ;-)

Ciao.

#242468
Mar 30, 2013 at 1:53pm

Hi Nicolas,

FWIW : actually InScore is undergoing development actively, i had a class by his creator (D. Fober) and he’s working on it at GRAME. It’s still a quite early stage of developpement, that’s for sure, originated last year or before. I’m less sure about Guido, it seems an older project, though the sf repo indicates recent activity (13/03/2013).
Thouuugh…indeed, for your needs, “Belle Bonne Sage” seems cool :)

#242469
Mar 30, 2013 at 2:27pm

Hi vichug,

thanks for the info ; i’ll follow it.

(To be honest i have not explored both enough to have a valuable opinion).

#242470
Mar 31, 2013 at 5:47pm

Hi,

one supplement: The FTM-editor was:
“implemented in Juce and integrated into Max/MSP using mxj”

http://ftm.ircam.fr/index.php/A_brief_introduction_to_FTM

But is now using juce/jgraphics implemented and integrated as a c++ ext:

http://ftm.svn.sourceforge.net/viewvc/ftm/trunk/ftm/externals/max5/ftm.editor.cpp?revision=3602&view=markup

What I think is interesting about this is that it might be worth considering that using a different language for the integration than the one used for implementation can be an advantage. Although I have no idea how this could look like in detail.

If you migrate to linux, will you stop using max/msp?

Greetings,
Alex

#242471
Apr 1, 2013 at 6:16am

Hi,

1. Thanks very much for the link to the FTM repository. I didn’t know it.

2. At the beginning I had the vague idea to wrap the code in a Python module ; then i had a look on Tcl, Ruby… but finally i chosed to go only with C++ mainly for multithreading ; AFAIK most of interpreters needs a global lock to deal for multithreading safety, and i guess that is not very nice in a “one thread per agent” scenario.

3. If you migrate to linux, will you stop using max/msp?

I will… but i said that since one year now, and i’m still using Max/MSP !!! I guess i’m too used/addict to easily swap to Pd, SuperCollider or something like that ;-)

#242472

You must be logged in to reply to this topic.