Praxis - InterMedia System

Shared Code
#1

Well, I’ve finally got around to putting a binary build of my project Praxis up at http://code.google.com/p/praxis/ Whether the project as a whole is of interest may depend on quite how wide your definition of games is :slight_smile: , but as this forum has been a great help I thought I’d at least post it here.

So, what is it??? Praxis is a framework for playing with a range of media (video/image, audio, MIDI, etc). I use it for creating interactive things in real physical spaces, as well as occasionally for audio(-visual) performances. You can get a rough sense of what I mean from this video (http://video.google.com/videoplay?docid=-1631892283027158552) - an interactive space using webcam movement detection to control audio and image (this was actually created with Praxis’s predecessor), or this performance (http://www.youtube.com/user/richardbolam#p/u/1/1zZfSWjcWAI - second one in).

At its heart, Praxis satisfies two needs I had. Firstly, it’s a framework based around a loose mix of dataflow / actor model, allowing proper communication back and forth between various media threads (synchronized really is evil in this scenario!). Secondly, it’s completely configurable at runtime - it has it’s own simple scripting language which hides all the complexity of passing messages back and forth, and also uses Janino to allow embedded fragments of Java code.

As a whole it’s GPLv3 (to satisfy various dependencies). However, I’m trying to release various modules from it under more liberal licences where possible (either GPL w/CPE or LGPL). At the moment, there’s various audio server and audio processing stuff under more liberal licences, as well as a binding for the JACK audio library using JNA. There should be more to come - the audio routing library could probably be with CPE too. Although everything’s built as a NetBeans module, as Praxis uses the NetBeans runtime container, only the player module depends on NetBeans API’s so the library JARs should just work.

It’s still got a way to go. Next on the list is a hardware accelerated video pipeline (using Slick most likely), better live coding API and a graphical patcher environment. Oh, and better documentation :slight_smile:

Feedback is appreciated, but feel free to ignore if it’s not your thing! :stuck_out_tongue:

Best wishes,

Neil

#2

Well, due to the overwhelming interest this provoked last time! :stuck_out_tongue:

Just a quick note to say that I’ve put up a first release of the graphical patcher-style environment for Praxis at http://code.google.com/p/praxis/ The live-coding API has had some improvement too.

I realise that the project as a whole may only have limited interest to people on here, but some of the libraries that make it up (thinking particularly the low latency JavaSound stuff) might - the project is highly modular, so it’s possible to just drag these JARs out, but I’ll aim to get some separate downloads and docs up in the near(ish) future.

Praxis is developed and tested on Linux - most things should be cross-platform, but YMMV with the GStreamer and JACK support.

Best wishes, Neil

#3

Looks really neat! Great job :slight_smile:

#4

A third early-access build of Praxis LIVE is now available for download from http://code.google.com/p/praxis/ This release includes the start of OpenGL support (based on LWJGL, with a bit of code “borrowed” from libGDX), a new Settings API, and improvements to the Projects system, as well as a range of smaller improvements and bug fixes.

A first beta release is planned for (hopefully!) the end of the year, bringing graphical editing of control panels (GUIs) and MIDI bindings, improved OpenGL support, a range of new audio, video & control components, and improved documentation. Features planned that may not make it into the first beta, though work has started, include support for live-coding GLSL video effects, and the ability to export Praxis LIVE projects as standalone applications.

Read the full release notes - http://code.google.com/p/praxis/wiki/ReleaseNotes

The most exciting bit for me is finally getting into implementing the OpenGL renderer. Above you can see a live webcam image of yours truly disintegrating into over 10,000 particles using the OpenGL pipeline. The particle code is live-compiled Java inside a code component, all editable on the fly and using a subset of the Processing API. Once more ops are hardware accelerated, what’s there is more optimised, and it’s possible to get live-compiled GLSL shaders in there too, this could get fun! ;D

Also interesting is that even though the OpenGL pipeline falls back to the software renderer for a lot of Ops, when doing things where nothing is accelerated apart from the blit to screen it still seems better than the software pipeline using BufferStrategy.

#5

It is rather a LWJGL renderer…

#6

I’m beginning to think you’re just a bot that pops up in any thread that mentions LWJGL. :-* You could have just as accurately said it’s a Java renderer or a (heavily hacked) libGDX renderer. What exactly is your point??? That JOGL exists - I KNOW!!!! I had to make a decision one way or the other, and after weighing up the options I plumped with LWJGL (which of course you disapprove of). The Praxis renderer could be refactored to use JOGL or any other binding very easily - direct references are only in a few classes - but until I have a compelling reason it’s staying as it is.

Praxis also uses JNA for other things, which I know you also have some irrational fear of … :wink:

#7

According to someone else, I’m Stallman’s bot. According to you, I’m a JOGL bot. I only pointed out some inaccurate words about your renderer and I’m coherent, I have never written that I use any OpenGL renderer because there is a difference between using OpenGL and using a Java binding of OpenGL as a Java binding contains some features about windowing system (as far as I know neither LWJGL nor JOGL contains a complete binding of GLUT). I’m not a bot, I’m a human being, I may disagree with some JGO members, it does not mean that I’m a silly bot, I may have some real reasons to disagree with them.

It is not irrational, you have just forgotten my rational objections especially about less good performances than JNI, I spoke about the mechanism used by JNA on Microsoft Windows… I don’t fear JNA, I just don’t use it, I prefer using GlueGen.

#8

Actually, I find your wording inaccurate because you’re mixing up renderer and windowing system.

JNA is slightly slower than raw JNI, but performance is never the only consideration - if it was we wouldn’t be using Java! :wink: Bear in mind we’re talking about call overhead, which should be swamped by code that actually does something in any real world use. Not using yourself is one thing - explicitly refusing to use anything that uses it whether it works or not is irrational.

If I remember what you said correctly, your comments about JNA on Windows were completely inaccurate anyway!

#9

I don’t mix up anything as JOGL and LWJGL have their own windowing system and they can still interoperate with AWT and Swing. My wording was intentionally accurate. Actually, when using a renderer relying on these bindings, you mainly have the choice between using the windowing systems or toolkits provided by Java itself or using their windowing system… except if you really want to create a binding of GLUT or if you prefer using directly the windowing system of a given platform. What’s wrong with that?

I remind you that I had spoken about Microsoft Platform Invoke (which is used by JNA on Microsoft Windows) and its bad impact on performances in the C# binding of OpenGL in OpenTk (previously in Tao Framework). Sorry for the off topic.

#10
So there's these three blokes sat in a pub when suddenly one of them jumps up and starts shouting abuse at the other two. He becomes more and more enraged til he finally takes off his hat and chews at it in frustration before throwing into the face of one of the other two. "Well, that's out of order!" says the bloke who was hit, and the third one says: "Don't mind him, he's just got a bad hat he chewed!"
#11

@gouessej

Thanks for derailing my thread! :cranky: I understand, and am already aware, of the points you’re making. However, I still intend to use the term “OpenGL renderer”. Even if the term “LWJGL renderer” might be more accurate at this particular time, and I still disagree that it is, I don’t think it’s in any way more understandable to people here or the project’s wider audience. It’s not like I’m hiding the fact that it’s implemented with LWJGL. Other projects in the same space (Field / Processing) using JOGL also use the term OpenGL renderer, though interestingly Field is currently converting to LWJGL.

In regards to JNA, it has nothing to do with Platform Invoke, which AFAIK is a CLR technology anyway. JNA is implemented using libffi. Still, I know you’ve already been told this … ::slight_smile:

@SimonH

Thanks for lightening the mood around here! ;D Perhaps a case of mercury poisoning?!

#12

Libffi has been removed from Mono for performance reasons (see r724) as far as I know and it uses the same underlying mechanism that Microsoft P/Invoke which is used in OpenTk.

#13

The only thing I can find on that suggests it was removed in 2001! Are we really taking over 10 year old performance as accurate of today, because … gee … this Java thing ain’t half slow! :wink:

If you really want to argue the merits either way of all this, please start a new thread. I only mentioned JNA in the first place because I knew it was the other choice you’d disapprove of! Personally, I’ll use what works best for me - which means easy to develop and deploy as well as good performance. Unless or until I or anyone else has a specific performance issue with Praxis or the various libs being released from it, then I have no interest in changing. And I’d rather help contribute to making JNA faster, which (in a minor way) I’ve just done!

#14

Well, a new release of Praxis LIVE is up at http://code.google.com/p/praxis/

http://wiki.praxis.googlecode.com/hg/PraxisLIVE-120620-sm.jpg

Highlights include

  • a live-coding GLSL component
  • a range of other new components, including new audio effects (chorus / flanger / reverb)
  • cross-platform capture / webcam support (Linux been there for a while)
  • optional GStreamer plugin for Windows (32/64bit) that doesn’t require a system install (should be adaptable for any Java project)

Blog post about the release - http://praxisintermedia.wordpress.com/2012/06/21/praxis-live-build120620/

#15

this is obvious coming from me of course…
But if I want to just display video cutscenes in my game.
Without the user having to install anything, and running on all 3 platforms,
is Praxis a viable solution to do this ?
and if so, how hard would that be ?

#16

LOL ;D

Praxis is about a 100x more (code and features) than you need for that. The GStreamer plugin might be useful to look at in terms of bundling GStreamer. Only slight issue is that the GStreamer build from Processing I used is the GPL one - you’d have to manually remove the GPL plugins in there. You’d also have to remove the one NetBeans platform reference (used to work out the library folder) and also extract the GStreamer libs from the plugin download.

The plugin source is in the ext repo - http://code.google.com/p/praxis/source/browse?repo=ext

Why not download Praxis and the plugin and see if it works for you?

#17

I tried “New Project”, and click the “Next” button … and nothing happens. The “Open Project” button and menu item also do nothing. :frowning:

#18

hmm … I can’t reproduce that, and a few other people have been fine too.

A few questions -

  • What OS and JRE/JDK are you on?
  • Does the popup menu in the Project tab also not work?
  • Does deleting your Praxis configuration directory (details at the bottom of the release notes online) help?
  • Zip distribution or installer?
  • Have you used NetBeans on that setup? (Praxis pretty much uses the NetBeans project system as is)
  • Anything show up in View / IDE log?

Thanks, Neil

#19

Praxis LIVE build 120711 is now available to download for Windows users only. It fixes an issue with Java 7 that only affects Windows users (so there isn’t an additional Linux / OSX release).

@sproingie - didn’t hear back from you, but wondered if that’s the cause of your issue too?

#20

The updated version seems to have fixed the issue. Now to learn how to use this contraption :slight_smile: