Author Topic: New Software  (Read 24204 times)

Offline csf

  • Moderator
  • Sr. Member
  • *****
  • Posts: 118
New Software
« on: November 15, 2010, »
I honestly fell I have a software design in mind  that will make sequencing our displays much easier, especially for things like this.

I hope to have some of it done in time for personal use for my show next year. I plan to release what ever I make as part of xlights.

Problem for me is for me, as a college student I am left with almost no free time to develop the software between college and work. I hope to at least get some of the base done over winter brake, and hope I get some more free time after I graduate in Jun. But with that being said I in no way can guarantee the time frame for this project and when it may be usable enough.

Now if there are programmers out there that want to help develop the project let me know. All I ask is that any software developed based of the ideas are released under the xlights project. (basically means a free, open source, cross platform program (preferably using wx widgets))

Offline magic8192

  • Sr. Member
  • ****
  • Posts: 276
Re: New Software
« Reply #1 on: November 17, 2010, »
Check out Prancer
You are not allowed to view links. Register or Login

Offline frankr

  • Sr. Member
  • ****
  • Posts: 347
    • Rocklin Lights
Re: New Software
« Reply #2 on: November 17, 2010, »
csf,

I sent you a PM to express my interest in helping you out.  I am not sure what the concept your looking into is but I personally do not see any of the current solutions as the "right" answer yet.  I think there is still plenty of room for some more innovation on the software side.

Frank

Offline csf

  • Moderator
  • Sr. Member
  • *****
  • Posts: 118
Re: New Software
« Reply #3 on: November 20, 2010, »
Just so every one knows the reason I bought this up in the smart string section was because of people talking about the issues with sequencing devices like smart strings.

Prancer does sound rather interesting and promising. Once it's open for public testing I will definitely be giving it a try.

frankr I am sending you back a pm right now.

It's been a crazy week of college or I would of gotten back to you all sooner.

Offline RJ

  • Administrator
  • Sr. Member
  • *****
  • Posts: 8519
Re: New Software
« Reply #4 on: November 20, 2010, »
We understand,

 It is not a problem, often great threads get started from thoughts on another thread. But they also sometimes get lost by being inside the original thread. So when I see a thread hit a strong note of a different sort I usally move it to the proper place to be noticed and found later. I messed up and put in a new thread but still in Smart Strings so he moved it to a better place.

I posted this long post for the benifit of all because I have had to answer this in pm a few times when we move thread. As I told one member, if the post was a problem we wouldn't move it, we would delete it and pm the user about it.   ;D

So when we move a post it means it has value on it own, and should not fade away inside another titled incorrectly.

RJ

Innovation beats imitation - and it's more satisfying

Offline rrowan

  • Administrator
  • Sr. Member
  • *****
  • Posts: 5899
  • 08096
Re: New Software
« Reply #5 on: November 20, 2010, »
Hi CSF,

My apologies if the move caused any problems. Like RJ said the topic is an important one because we all know that the current software while great is not really ready for RGB leds and the large channel count. 

Please continue your ideas

Cheers

Rick R.
Light Animation Hobby - Having fun and Learning at the same time. (21st member of DLA)
You are not allowed to view links. Register or Login
Warning SOME assembly required

Offline rrowan

  • Administrator
  • Sr. Member
  • *****
  • Posts: 5899
  • 08096
Re: New Software
« Reply #6 on: November 20, 2010, »
Been thinking about this some more and I guess the better spot would of be the "New Stuff" forum since we currently don't have a Software New Stuff forum LOL

Cheers

Rick R.
Light Animation Hobby - Having fun and Learning at the same time. (21st member of DLA)
You are not allowed to view links. Register or Login
Warning SOME assembly required

Offline csf

  • Moderator
  • Sr. Member
  • *****
  • Posts: 118
Re: New Software
« Reply #7 on: November 20, 2010, »
Thanks' for the explanation.

I just didn't want any one thinking I was trying to hijack the thread.

I sent a pm to frankr with the main ideas, lets see how they develop, and maybe in a few weeks I can formally layout all the ideas for every one to read over and give feed back on :)

Offline ptone

  • Sr. Member
  • ****
  • Posts: 107
Re: New Software
« Reply #8 on: November 22, 2010, »
So in what sort of ways are you thinking of something different from Prancer or what I'm working on (You are not allowed to view links. Register or Login). 

I think it is a very hard job to find the sweet spot between sophisticated enough to handle complex ideas for sequences, but easy enough for the hobbyist to use.

With my own work, I'm definitely leaning towards flexible and sophisticated, and at this point don't even plan a GUI (strictly a scripted solution).

-Preston
--
budding channel wrangler

Offline csf

  • Moderator
  • Sr. Member
  • *****
  • Posts: 118
Re: New Software
« Reply #9 on: November 22, 2010, »

Quote
So in what sort of ways are you thinking of something different from Prancer or what I'm working on (You are not allowed to view links. Register or Login).

I think it is a very hard job to find the sweet spot between sophisticated enough to handle complex ideas for sequences, but easy enough for the hobbyist to use.

With my own work, I'm definitely leaning towards flexible and sophisticated, and at this point don't even plan a GUI (strictly a scripted solution).

-Preston

Honestly it's a bit hard to say exactly what the differences will be since nether your program or prancer has a verson available that I can try my self.

 I will point out a few things though that I do believe to be differences.

First basically think of my program as a cross between q lights and vixen.

The program will not eliminate a grid completely but will use the grid in an entirely new way. Think of rows as layers then channels.

Channels will be groped, effects placed on to groups, and then effects / groups added to the time line. 

This program will also be open source, which is a big plus for me. I rather be able to use a program I can customize and change then a program I am stuck with.

Also one of the biggest motivations for me is my want to be able to sequence using my MAC. I know prancer will be PC only since it requires .net I am not sure about your program yet, but I don't remember any thing about what OS you are supporting.

Offline ptone

  • Sr. Member
  • ****
  • Posts: 107
Re: New Software
« Reply #10 on: November 22, 2010, »


You are not allowed to view links. Register or Login

 I will point out a few things though that I do believe to be differences.

First basically think of my program as a cross between q lights and vixen.

The program will not eliminate a grid completely but will use the grid in an entirely new way. Think of rows as layers then channels.

Channels will be groped, effects placed on to groups, and then effects / groups added to the time line. 


So will the timeline be segmented in some way - or just time.  Both Prancer and Nestor (my working title) represent events just in time, with no assumptions about how that time is divided (at least that is what I understand about Prancer - its true of my project).  The advantage is that you abstract the rendering of effects from the way they are sent out over your signaling protocol.


You are not allowed to view links. Register or Login

This program will also be open source, which is a big plus for me. I rather be able to use a program I can customize and change then a program I am stuck with.

Also one of the biggest motivations for me is my want to be able to sequence using my MAC. I know prancer will be PC only since it requires .net I am not sure about your program yet, but I don't remember any thing about what OS you are supporting.

Mine will be open source once it is in a bit more shape - happy to share in it's current state for anyone to take a look (no docs, lots of test code, hacky bits etc).  I develop exclusively on a Mac, and am using Python for this - so in theory it should be cross platform.  But given the open source libraries it uses, will be easier to get working on linux than on win32.

As my project is starting to mature a bit - let me outline some of my approach.

I do assume channels over a signaling protocol and really just focusing on DMX.  The fundamental object of the system is a LightUnit.

A show object is a collection of light units.  The show handles the runloop at some given framerate, and in each loop gets current values for the various channels from each lightunit that has channel data to share (not all units have channel data, as we will see), and sends it out to a controller, currently I run this loop at somewhere between 40-100hz, depending on some factors and the fixtures involved.

A light unit may have channels of output, but might have other properties as well.  In the simple case, the main attribute mapped to a channel would be it's current intensity (0-255).  Each time through the show loop, the show asks a simple light unit for its channel data - if it has intensity as a channel value, then the DMX universe gets updated with that value.  But a light unit might also have a set of attributes related to a fade envelope, which modifies the intensity value over time to control a ramp up and ramp off behavior (attack, and release). 

LightUnit represents a base class, upon which many subclasses might be built.

For example I currently have:

LightUnit
    RGBLight
        StageApePar38 (a specific Par38 DMX fixture)

An RGB light can have a Hue property, that will auto adjust R, G, and B channels when it is changed.  So if you have something like:

tree_flood = RGBLight()
tree_flood.hue = .3 # from 0-1 = 365 degrees of Hue in HSV color space

this will auto set the R,G,B attributes, which themselves are mapped to channels

A lightUnit need not be a light - there are subclasses for groups of lights, there are subclasses that handle chases.  In these cases, the units don't output channel data themselves, but on each update of the show, may change values of their light elements.

Speed of a chase, changes in color or brightness etc can all be "tweened", that is changed in a non-linear way corresponding to a curve function, this option for non-linearity is key to an organic appearance.

Now all these lightunits are sitting bundled up in a show that asks them for  current state - how do they change over time, what is causing the change?

The lightunits (including chases etc) respond to a trigger or signal.  A signal may just change some property (for example increase the decay rate of the fade), or may trigger the light to come on, or sequence to start with some initial value.

These signals my come from some form of realtime input, or may come from a file of pre-recorded events.  The key is that this signal layer does not contain the detail of information that ultimately goes out to the light channels.  A single trigger event may start a chase sequence of 25 lights, each of which have attributes that cause them to fade out slowly after coming on.  So what you have in effect is a rendering of the channel data from the signal data through a set of lightunits that define behaviors.  This is the key element to this design.

There can be multiple, alternate methods of generating the signals.  One of the main methods is MIDI.  MIDI was design to capture the expressive performance of musicians.  When I think of good light shows, I think of something that has the fluidity of Dance or Music.  Many many of the vixen sequenced light shows have a very mechanical techno blinky look to them, and I think this comes from having to sequence while staring at a screen and imagining the music and how the lights might look - very hard to do, and so you end up with something that is not all that organic in appearance.  The idea with MIDI is to reverse the standard way people sequence their shows.  Which involves planning them out, then sequencing, then installing the lights.  The previews do help a lot with this - but I want to just put up the lights with some idea of structure, pick a song, go out into my front yard and play the lights on the keyboard (laptop, or MIDI).  I want to be able to easily improvise along with the music.  Doing multiple "tracks" of this so first I might just play the drum part - next record a bass part (while the drum part plays back on the lights). Ultimately I want to spend only 10-15 minutes sequencing!  MIDI is also something out there that has some great sequencing software already - so a GUI editor comes "free" with that.

Now MIDI note messages to light triggers is the obvious part of the signaling, but there is also MIDI control data.  I have this cheap little MIDI keyboard, and it has 10 dials and a couple sliders etc.  These send MIDI controller messages.  In my software I map these to other attributes.  For example the speed of a chase, or the color of a light, or the frequency of a strobe effect etc, so you can tune the behaviors of lights at runtime.

Once all these tracks are recorded - they can be played back as a sequence.  But if you want to change the drum part to another set of lights, the signal data is not bound to certain DMX channels, and you can redirect that signal to different lightunit(s).  Keeping these two parts of the process separate keeps things flexible - but could result in some performance issues.  If the complexity of the show is too great for the CPU of the machine to process in realtime, then there is the option that the show could be "compiled/rendered" into raw channel value files (or even a vixen file).  But because the behaviors are based on time, and not frames, the framerate can be reduced for the live recording part (reducing CPU load) and then cranked up for the compile/render of the final channel data for higher resolution, smoother fades.

In addition to MIDI, one could also trigger lights with the Kinect sensor as demoed, or an iPhone touch interface (I have the first one working in rough form, and plan to do the iPhone one - they actually are very similar in some ways).

I've also added some features more applicable to a theater setting - but could be fun in the blinky context.  The idea of a set of scenes and transitions.  So you can have a certain set of values for all your lights and define that as a scene.  You can then transition to any other defined scene, and all of the changes needed will be blended from any one scene to any other - these could be useful for floods that you want to change in response to chord changes in a song etc.

Whew - so there you have it, a pretty long explanation of what I'm working on - like I said, no GUI planned, but I want to get the fundamental ideas nailed down in code.  Also it would be hard to come up with a GUI that gives you all the power exposed in such a framework.

What language/framework were you planning to use?  You can see from the Prancer effort, this is no small task.

-Preston
--
budding channel wrangler

Offline csf

  • Moderator
  • Sr. Member
  • *****
  • Posts: 118
Re: New Software
« Reply #11 on: November 22, 2010, »
Very Interesting ideas. Thanks for explaining it. Now I also found the link in the first post that explains the project better... I thought that had to do with the name ideas so I skipped over it originally...

I definitely like that it will be a mac program, and will be open source :)

Now do you plan on allowing for any thing other then MIDI input eventually? Unfortunately for people like me where not talented enough to compose our own music.

My plan would be come two applications inside of xlights with my current idea. I would have a console based application where you can set up groups, effects, and run a live show if you wished.  The second application would be a sequencer that  will allow you to place the stuff from the console on to a time line.

My time line would be time based just like Vixen or LOR S2. Except what you put on the time line would be different.

The programs would be built using WX widgets for cross platform comparability.

For light controle / playback it would make use of the libraries dowdybrown has made / expanding. Currently xlights  supports LOR, Dlight, DMX, and Renard devices, with more protocols support on the way.

Xlights has a sequencer already that can be used for scheduling and running shows, and also has a scripting language in the scheduler that can be re used for the console / sequencer.

If you are writing you program completely in python it may be worth looking in to making a xlight program that then uses python as the scripting language in which the script would be your program. I know I have scene other programs do this, but my experience with python is limited to making script for other programs with it.  If you can get it all working in side xlights dowdybrown, and me can probably help you  after the holidays, you then concentrate on you sequencing ideas, and just send things like playing a show or protocols over to the already existing parts of xlights. 

Once nice part about x lights is we tried to make it as versatile as possible so people can create there own applications in side of it leveraging the already existing parts of the program. 

But if you rather have your own program entirely and not make it part of x lights I fully understand.

Offline ptone

  • Sr. Member
  • ****
  • Posts: 107
Re: New Software
« Reply #12 on: November 22, 2010, »
You are not allowed to view links. Register or Login
Very Interesting ideas. Thanks for explaining it. Now I also found the link in the first post that explains the project better... I thought that had to do with the name ideas so I skipped over it originally...

I definitely like that it will be a mac program, and will be open source :)

Now do you plan on allowing for any thing other then MIDI input eventually? Unfortunately for people like me where not talented enough to compose our own music.

did you see my explanation of other inputs - MIDI is just one.  But let me clear up a large and recurring misunderstanding people keep having about the use of MIDI.  Just because MIDI was designed to capture notes of music, does not mean that is the only way to use it.  If you are sequencing a song - a single key on the keyboard may be used for the entire base line.  You do not need to be able to play the song, just tap out parts and roles of the show.  If your lights are "dancers" and you are the choreographer, then all you need is some rhythm.  If one has no rhythm or creative energy for a light show - why do it.  But one does NOT need musical talent or the ability to play a piano etc.


You are not allowed to view links. Register or Login

My plan would be come two applications inside of xlights with my current idea. I would have a console based application where you can set up groups, effects,

Here you will have to figure out more what you mean - groups of channels, groups of lights (lights will have more than one channel) etc.

You are not allowed to view links. Register or Login

My time line would be time based just like Vixen or LOR S2. Except what you put on the time line would be different.

Do you understand the difference between a timeline that has a grid to it, vs one that is just time?

You are not allowed to view links. Register or Login

For light controle / playback it would make use of the libraries dowdybrown has made / expanding. Currently xlights  supports LOR, Dlight, DMX, and Renard devices, with more protocols support on the way.


OLA (opendmx) already supports way more DMX output options.  It does not support renard or LOR, but we should ask dowdy to support OLA.  xlights won't work with my E1.31 based EthConGateway, nor RJs new PixelNet Dongle.

You are not allowed to view links. Register or Login

Xlights has a sequencer already that can be used for scheduling and running shows, and also has a scripting language in the scheduler that can be re used for the console / sequencer.

By the time you have a system that can play a complex show - a scheduler is the easy part.  I'll probably just use cron or launchd for starters, or a web based trigger for "on demand" shows.

You are not allowed to view links. Register or Login
If you are writing you program completely in python it may be worth looking in to making a xlight program that then uses python as the scripting language in which the script would be your program.

Sounds kind of inside out to me ;-)  What is an xlights program?  Is there an API - what is the framework it provides?

You are not allowed to view links. Register or Login
I know I have scene other programs do this, but my experience with python is limited to making script for other programs with it.  If you can get it all working in side xlights dowdybrown, and me can probably help you  after the holidays, you then concentrate on you sequencing ideas, and just send things like playing a show or protocols over to the already existing parts of xlights. 

Yes, Python is often the choice of an embedded scripting language, but it is a pretty full fledged programming language on its own and has lots of horsepower for this sort of work.


OLA is handling the sending of light data quite well for now - the main thing is I don't have a way to send out to LOR or Renard channels.  If there is a way to use xlights as an output device that would be cool - it would need some soft of streaming client API.

You are not allowed to view links. Register or Login
Once nice part about x lights is we tried to make it as versatile as possible so people can create there own applications in side of it leveraging the already existing parts of the program. 

But if you rather have your own program entirely and not make it part of x lights I fully understand.

Are there any docs for writing to an xlights API?

So you plan to write straight C with the cross platform widget GUI then?  I think the more the merrier in this game, but I can also say being part way into it, that it is a large and complex problem with lots of design decisions needed along the way.

Look forward to watching your progress.

-Preston
--
budding channel wrangler

Offline dowdybrown

  • Moderator
  • Sr. Member
  • *****
  • Posts: 358
    • Gleannloch Christmas
Re: New Software
« Reply #13 on: November 22, 2010, »
Since xLights is based on the wxWidgets library, one option would be to translate it to Python and use the wxPython libraries.

I planning on adding E1.31 support after this holiday season.

xLights will be running my show this season -- LOR sequences output to 3 DMX universes (1000+ channels), no iDMX.

Matt
Matt Brown
You are not allowed to view links. Register or Login

Offline ptone

  • Sr. Member
  • ****
  • Posts: 107
Re: New Software
« Reply #14 on: November 23, 2010, »
OK, so many cool things to do.  in the latest IOS 4.2, they've added CoreMIDI support as well as websockets.

The websockets can be used with javascript touch events to drive the lights similar to the way the kinect does.

Also, in addition to MIDI, I will build in an OSC signal plugin - and OSC is more flexible than MIDI, and one could use the cool touchOSC app.

so much to do...

-Preston
--
budding channel wrangler