Support for Java Swing UI...
I am some what familiar with Java, but am unsure as to what
Java APIs are supported by Max. I was wondering if someone
could help guide me.
I am investing the feasability of porting a Java timeline
app to Max. This app uses Java Swing for its gui. Does Max
supports Java Swing? If not, what api does it use for graphics?
Thanks,
Anthony
Anybody?
in the interest of having *any* reply rather than a correct one, here goes..
as far as i know, you can use any java libraries within mxj, potentially
including
AWT/Swing. that being said, AWT/Swing threading is more complicated
than it seems,
and the threading interactions might be a possible source of error or
frustration. not to
mention you'll have another top level window for your gui - maybe switching
back and forth between the two? as far as i know, there is no bridge to
allow display of
AWT/Swing components, for instance, in a jit.pwindow.. btw,
JMonkeyEngine does
purportedly push AWT/Swing into opengl, but I haven't poked around there
too much yet.
as far as "what gui toolkit" does jitter use, that is a rather large
question. there isn't really
a named handle for all these things, but for on-screen gui controls
there are many options
including built in messages, checkboxes, etc. and things like ubumenu..
you might argue
that the max programming language itself is a gui..
for other stuff, i would look at pwindow.. for controlling the level of
user interaction with your
max patches with interactive guis there is also a new presentation mode
in max 5..
there are some examples also of generating gui stuff from java within
max/msp/jitter.. i'm
thinking of a slider example which renders in a jit.pwindow in
the examples Max5/examples/jitter/java
hth,
Anthony Palomba wrote:
> Anybody?
>
It's been a long while since I've done it, but yes, you can develop using Swing within Max. The one thing I remember, which stopped me dead in my tracks, was that the Swing application had to live in its own window - you cannot embed Swing UIs directly within the Max window.
So for your potential timeline application, know that the actual timeline would need to live in its own, separate window than the rest of your Max-based application.
HTH,
Dan
Thanks for the responses. What I am looking to port is a
composition environment called Blue...
http://www.csounds.com/stevenyi/blue/
http://www.csounds.com/stevenyi/blue/screenshots/pythonScore.png
It is used as a front end GUI for csound. I have used it before
and have found it to be a very intuitive interface. A lot of the
csound specific stuff could be stripped out, leaving the time
line and sound object editor.
Basically the time line would sequence sound objects. A
sound object can represent many things, whether it is a single
sound, a melody, a rhythm, a phrase, a section involving phrases
and multiple lines, a gesture, or anything else that is a
perceived sound idea. Multiple sound objects can then be organized into a Poly Object.
Having something like this in Max would be awesome. There would
be a lot of event data being passed via Java to the rest of Max.
Not sure what kind of performance bottle neck that might be.
Right now I am just trying to get my head around the amount
of work that would be required to port it.
Sorting out all the GUI stuff might be a real pain in the ass,
another option might be to lift the relevant parts
and convert that Java source to C++.
Does anyone have any thoughts on which might be easier?
> Having something like this in Max would be awesome. There would
> be a lot of event data being passed via Java to the rest of Max.
> Not sure what kind of performance bottle neck that might be.
It's never affected me in my small Java Max efforts, but from what I've read
on the forums over the last few years, it's the Java Max bridge, and
multiple crossings of it, that will cause you performance problems. So
yeah, this might be where the thing blows up for you...
> Sorting out all the GUI stuff might be a real pain in the ass,
> another option might be to lift the relevant parts
> and convert that Java source to C++.
>
> Does anyone have any thoughts on which might be easier?
Do you just want a timeline/piano-roll editor for Max? If so, my gut tells
me that just starting from scratch in C would be easier than
porting/stripping the Blue application. But I could easily be wrong!
We *do* need a good piano roll editor for Max though, so you have my
encouragement!!
Dan
--
Dan Nigrin - Defective Records
202 Hack / PC-1600 User / VSTi Host / Jack OS X / Major Malfunction
http://defectiverecords.com
http://jackosx.com
On Dec 1, 2008, at 5:54 AM, Anthony Palomba wrote:
>
> Anybody?
Search the Java forum for "Swing". There have been some discussions
that may be informative for your needs.
-Joshua
It is possible to use Swing within Max/MSP. The text editor for quickie
is written entirely in swing. The only real caveat is that the swing
part of the UI must live in a separate 'swing' window.
I spent a decent amount of time working on a solution for embedding
swing components directly within the patcher but abandoned the notion
after it was determined that the work vs usefulness quotient leaned far
more in the 'work' direction. Parts of swing really aren't 'pure' java.
This was the biggest problem. There were some components that still were
dependent on native OS peers which immediately complicates things since
you get into multiple event loops etc.
On top of that all of the swing event handling would need to be
reimplemented so that carbon events could be turned into swing events.
For instance, when you mouse over an embedded swing button in the
patcher you need to figure out what button it is and generate an
appropriate event, invalidate appropriate child parts of the swing ui
etc. This part is possible but was gummed up by the lingering OS level
component dependencies.
That said. If you don't need your swing components embedded in the
patcher and they can live in their own window it is pretty straight
forward to get swing up and running. The biggest thing to remember is to
make sure you deal with the event dispatching thread properly when
responding to events generated by swing otherwise you can get
deadlocking. This is more of a problem on OS X than windows. If you use
SwingUtilities.invokeLater() to run code in response to generated events
these problems should be minimized.
Like Joshua said though...this stuff is mentioned in the list archives
and probably in more detail as my memory is a little foggy.
T
Joshua Kit Clayton wrote:
>
> On Dec 1, 2008, at 5:54 AM, Anthony Palomba wrote:
>
>>
>> Anybody?
>
> Search the Java forum for "Swing". There have been some discussions
> that may be informative for your needs.
>
> -Joshua
>
Blue is not a piano roll, it is a user defined hierarchy
of sound objects, sequenced on a time line. These sound objects
can be anything, a piano role, sounds samples, MIDI file, etc.
If it were ported to native code, sound objects could even
be bpatchers.
On 1 Dec 2008, at 21:00, Dan Nigrin wrote:
> Do you just want a timeline/piano-roll editor for Max? If so, my
> gut tells
> me that just starting from scratch in C would be easier than
> porting/stripping the Blue application.
I tend to build this kind of UI by doing the heavy lifting in Java and
the (simple, stateless) graphics in JSUI.
-- N.
Nick Rothwell / Cassiel.com Limited
www.cassiel.com
www.myspace.com/cassieldotcom
www.last.fm/music/cassiel
www.reverbnation.com/cassiel
www.linkedin.com/in/cassiel
www.loadbang.net