Bitte haben Sie Verständnis, mein Deutsch ist nicht perfekt, deswegen schreibe ich folgendes in englischer Sprache.
Since some time I have been thinking about and working on a light effects controller software, in the first place for an RGB dancefloor I already purchased the hardware for, but couldn't still finish because lack of time (soldering all those tiny SMD components ). But now vacation time comes, and I'll try to make free several hours a day for this. And yes, Java of course will be the language of choice for the controller software.
Talking about my project, software will be closed source but with scripting facilities and an open Java API, somehow among the lines of Processing, but with a more simplified API and with functions more apt and optimized for low-frames-per-second LED matrix animations. For small and medium installations, software will be provided completely for free, with some fee for bigger installations (and commercial pricing for the really big installations). Also I will be open in the future to exchange source code and/or licenses for hardware (RGB pixel hardware, dmx interfaces etc. - the latter for being able to test and develop code further).
There will be API hooks for effects and output modules, code contributors with effects and outputs will be rewarded with free licenses for unlimited output RGB matrix sizes.
As a start, DMX limit of 44 frames/second (rounded to 50 frames/second probably) will be taken into account, but not much time will be spent in output modules for specific DMX interfaces, as the software will be in first instance for PC - Arduino/mbed(!) - WS2801(etc) pixel setups. Probably after that Artnet, finally (serial) DMX support.
Now the ideas:
1. Matrix setup and preview shouldn't be limited to square matrices, but it should also be possible to setup for eg. a Christmas tree illumination (conical arrangement of LED strings).
2. Using a fixed array of numbered buttons with predefined effects as some known commercial software is not handy in practice:
a) a user needs a paper written with the effects he assigned to each button, impossible to remember so many settings for 2 effect channels!
b) he's limited in the number of effects he can define by the number of available buttons, there's no way to group effects etc.; only saving effects and loading another bunch, he could predefine more than the number of available buttons
c) creating a cue of effects is not handy without seeing well, what you are doing
So I have the idea, there should be a button that opens some kind of "effects" folder with eventual subfolders, very similar to a folder in Windows, OSX, Linux etc. Inside the folder, there should be animated thumbs of the effect (animated gif, mng, apng or whatever - my idea is to use apng, as mng seems be dead, and gif is limited to 255 colors only). So a user can see immediately the effect he wants to choose, and effects can be combined / copied / moved inside subfolders at will. Also there's no limit to the number of effects that can be created and stored in the library. Using apng, even the whole effect setup could be stored in some proprietary chunk of the animated image itself, so even copying / moving / arranging the visual icons within W*ndows Explorer (or M*c Finder) would automatically also move the corresponding effects setup code!!
3. There should be some handy way (very similar to Gimp or Ph*toshop setup) to create / combine layers. So even it should be possible to use a predefined effect as a base layer to build new effects upon. For performance reasons, it should be possible somehow (but how I still have to figure out) to "flatten" a combined effect, same like you can "flatten" layers in Gimp and Ph*toshop. So this way, you could use a "flattened" existing (combined) effect as a base layer for new effects. Some tests will be needed to see the real need for "flattening", I suppose generating several individual effect frames and combining them with bitblt will have adverse effects if you want to do this 50 times a second.
4. Android API should be taken into consideration on building the software, there are so many great Android based tablets
5. A good astronomical timer should be incorporated, so it's possible to create long-running effect cues based on astronomical time (sunrise and sunset etc.).
6. For the future, a good external event trigger interface should be incorporated, so effects can be shown / triggered by some external event.
8. All stuff written to disk (gradients, effects, cues) should be in some human-readable and documented format (XML, json...), not in some obscure binary format.
I'm open to your feedback, please write it here or send me a mail (you can write in German, Dutch, Spanish or Portuguese also, I understand all perfectly).