Pixel Tree, is it possible& practical with Aurora

We have a design for a new editing paradigm which will facilitate much easier editing of sequences which span into tens of thousands of channels across dozens of universes.  Unfortunately, due to time constraints (Aurora 1 just turned 5 years old and needs replacement today), the new edit paradigm will not be included in Aurora 2.  Aurora 2 will easily be capable of controlling all of those pixels (the new render engine is implemented), but the editor will still be the "classic" approach with some enhancements.

Exactly when we will develop and include the better editor for thousands of pixels depends on the success of Aurora 2.

I'm sorry that I didn't have the answer you were hoping for regarding extensive use of pixels.

Regarding your other questions, yes you can convert your 1.0.90 sequences (non-DMX) to the 2.0 beta and continue to use your D-Light hardware.  You will be prompted for mapping the non-DMX channels into a DMX channel number.  Your D-Light hardware will require a new chip to support the DMX protocol.  At the moment that is a technical process involving a PIC programmer (several forum members here can help if you need), but we do plan (closer to release) to offer a PIC swap service to make this easier for those who do not wish to get directly involved with the PIC programming themselves.

Michael

We have not tested it with Aurora yet, but it is my understanding that LOR controllers with firmware 4.20 and above will function on a DMX universe (so no rechipping is required for your LOR controllers).

Michael

Just wondering if my post/question was overlooked?

Tks!

Thanks BigDPS. I suspected that due to the lack of response to my post. What I don't understand is if Aurora can control an RGB floodlight, basically a collection of LED's in a housing; why can't Aurora control a collection of LED's in a candy cane?

I'm a very happy Aurora user. One more night with the display up and aside from one lone random shutdown of the scheduler, Aurora has run great.

However, I'm concerned about the success of Aurora 2 and therefore the future of Aurora if it's still behind the technology of other software options that have the ability to control pixels. Why will a new user opt for Aurora 2 if other software programs provide more options?   

The above information is not entirely accurate.  Aurora 2 was not at all designed as an entry level software.  At the moment due to time restrictions only the entry level editor features are present, but the Aurora 2 back end (render engine) is designed for far more advanced usage (slice mapping, pattern overlays, etc.).  Getting those things into the front end is a matter of available time, not of capability. 

Unfortunately, we are at least two years out at the current development pace from fully implementing and testing those features, so rather than have customers who want a properly functioning DMX today wait until we get the advanced stuff complete, we've decided to release the less capable version now as version 2 and postpone the more advanced features for a future version 3.  That said, the program is certainly accessible to entry level users, but as a whole it is far from being an entry level design.  There is also the matter of continued funding to support development, so it is our hope that version 2 provides the necessary funding to continue into version 3 (and maybe some extra to advance some of those features into version 2).

Also, 1.x did not rely on .NET in any way.  FTDI drivers were an issue though, and an 11th hour (as in mid-November) protocol change done by a hardware vendor made us lose a lot of customers.  We've been retooling for DMX and E1.31 ever since in order to avoid that situation ever happening again.  There were also some other 3rd party dependencies which became difficult to support since Aurora 1 saw an unexpectedly long release cycle which outlived our own support channels for those dependencies.

The future direction of Aurora (what additional items will be included in version 2 and what will not) largely depends on the success/failure of the preorder discount closing later tonight.

I'm certainly never going to get rich writing this software (far from it, we've been at a loss for a few years now), but I do need something to justify the number of hours spent away from family.  Without that I do have to take other consulting work to pay the bills, and that is the biggest reason development has slowed in the last couple years.

Michael


Edited by LightsOnLogan - 31 Dec 2013 at 4:55pm