-
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))
-
Check out Prancer
http://diylightanimation.com/index.php?board=34.0
-
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
-
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.
-
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
-
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.
-
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.
-
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 :)
-
So in what sort of ways are you thinking of something different from Prancer or what I'm working on (http://diylightanimation.com/index.php?topic=3556.0).
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
-
So in what sort of ways are you thinking of something different from Prancer or what I'm working on (http://diylightanimation.com/index.php?topic=3556.0).
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.
-
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.
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
-
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.
-
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.
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.
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?
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.
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.
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?
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.
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
-
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
-
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
-
This is the PM I sent to frankr the other day I think it will help every one get a better idea of what I have in mind.
Basically my idea would eliminate the need to have one row on a grid for each channel in your light show.
The first part would be channel groups. If you wanted to use the sequencer traditional to control each item 1 by 1 then you can just make each group one channel. But now if you want to take advantage of groups you can put multiple channels in one group. Also channels can belong to more then one group.
Now for my show this year I have 80 channels, 30 of them give me control of 10 groups of RGB LED rainbow floods / spots. I also have 6 AC channels of red mines, 6 AC channels of green mines, 6 AC channels of color mines and 11 AC channels of white mines. The rest of the channels are more individually controlled so not much of a point in writing out what they control.
So right now if I want to use all the green lights I need to turn on 16 channels, if I want all red I need to turn on 16 channels, if I want all white I need to turn on 42 channels.
If I brake this in to groups then I would only need to turn on one group to turn on 42 channels of lights.
Also then next year when I plan to add more of these items to my display with red, green, color, and whit mines, I won't need to re do the whole sequence all I would need to do is add the new channels to the correct groups.
(now think of some thing like a smart string where to be all red may need to turn on 128 channels, or to be all white need 384 channels to be turned on)
Now back to the sequencer the rows of a sequencer would now work more as layers then as channels, unless you want them to be channels. Just select the group from a group window and click on the cells you want them to be added to.
I figure I could sequence my whole show in probably 6 layers (6 rows using this methods.
Now where things really can get powerful is by adding in effects. Effects can be made using some type of scripting language, xlights already has a scripting language, and we can eventually make a gui for making scripts for none tech users.
Effects are then applied to a group of channels.
Such as turn on the first channel in a group and then go down the line turning the next channel on and the previous one off.
Now to make effects really power full they will also take information from the time line it to account.
Such as a fade on the time line will automatically fad the effect of a group.
Also we can have smart effects, which will work similar to effects but have keys on a time line.
In my display they will be times where the lights will keep switching between, red, green, colored, and white.
Now I could make an effect that switches from one color group to another. And every place in the grid that has that effect live the effect will be up in one color, turn it off, turn it back on and the next color will be up.
If we really want to be creative we can use these smart effects to add some randomness to the display. So that each show will be a bit different. Like in the case of my show it really does not matter, what color (red, green, color, or white) is used, and which flashes next, as long as it's a different color then the color perviously on.
This would definitely make our displays have more of a re watch vale since it's never exactly the same. It would also add the the value of seeing the display live since, chancres are you wont be uploading a video or each version of the show to the web.
You can kind of think of it as a concert. The main show is the same each time, but each location its slightly different, which makes it unique.
-
csf,
With the software you have in mind, who is your target?
A musician? A tech savy? Or an average Joe?
I’m the creator of Prancer and this year I have created all my sequences using my alpha version, I’m not releasing to the public yet, first because still there is a lot to do and second and the main reason is because still is not “simple” enough to used for the average Joe.
Once you lock on the semantic of the software the user must learn how to use it, if the learning curve is high and then when you change some behavior you will be cursed since users need to learn new stuff.
Prancer is targeted for the “average Joe” and most of the users fall in that category, they don’t know midi or/and they just know computers enough to run Vixen, Vixen is a slow process but easy enough for anyone to understand, simple concept, every box represent the channel and intensity, that’s it, the semantic of the software is so simple that probably is the most used software in sequencing.
Unless they have software that guide in the process of creating a sequence then the assimilation of the software in the average public will be really slow.
Users in this hobby want to spend the time building the hardware, adding more channels or making a fabulous front yard with many colors and spend the less time as possible on the sequence creation, but everyone knows that the sequence is the heart of the show.
I’m sure in this hobby users come and goes every year, I bet the average user retaining ratio is no more than 2 or 3 years per user, and probably just a few are long recurrent users that make a show every year.
So, If there are two pieces of software, one is simple as Vixen and another one is incredible powerful but take months to learn how to use it, do you think a new user will go for the difficult path?
Take the following as a good intention comment.
If your software doesn’t have a GUI, what are the requirements (knowledge) for the average user to create sequences? Do they need to know scripting? How long is the learning curve? I mean if they have to spend 3 months to learn scripting what they get after that?
It’s awesome that someone is building something for MAC, someone has to take care of the MAC users, but again programming for MAC is like restore old cars, everyone love it but just few will use the service, basically you spend many hours on the software and because the target is MAC you collapse the target to the 5% of the general population, usually I look for 95% since I get more return for my bucks.
If the target is yourself then as long you are happy and makes your life easier then go all for it, it is an awesome sensation to create sequence with your own software, Also you mention Linux so the target may be is a tech user, if that is the case then be prepared to spend more time creating documentation than features, since tech user the first thing they go is for documentation.
Companies make specialized software and make a lot of sense for all platforms since on MAC or Linux is low volume high margin, but if the software is Open source what is the end benefit of it?
Windows 7 phone may look awesome and have better screen, more capabilities, don’t drop calls, and communicate with all social networks, but who the heck will program for it since IPhone and Android have more 100000 applications already out there. Microsoft will have to spend A LOT of money persuading programmers to program for it, and may be a lost cause already since the market belongs to Apple and Google.
Sorry if I sound too pessimist, I just want to make sure you have clear what are the reasons to create a new software, I may be missing something and I apologies if I didn’t understand your idea.
So may I ask, who is the target for the software you have in mind?
Cas.
-
csf,
With the software you have in mind, who is your target?
A musician? A tech savy? Or an average Joe?
Cas,
You address csf, but I feel some of your questions are also directed at me, so I'll answer from my perspective and hopefully csf will weigh in from his.
First thanks for poking in here - and you raise interesting points.
Myself, I am NOT writing software for the average joe. I'm writing my tools for the technically savvy - someone who wants to do very sophisticated things without a lot of effort or time. (this does not include time to learn scripting). For someone who understands programming in any language, I think the learning curve for what I'm putting together will be very small.
As you are seeing with Prancer, it is easy enough to come up with things that are powerful, or things that are easy to use, but VERY hard to come up with something that is both. If you are designing for the average joe, you will end up giving up power in trade for ease of use. I won't.
If your software doesn’t have a GUI, what are the requirements (knowledge) for the average user to create sequences? Do they need to know scripting? How long is the learning curve? I mean if they have to spend 3 months to learn scripting what they get after that?
for my tool some knowledge of scripting or programming is useful. But if you want to create a show with almost no limitation in sophistication, in a very short amount of time, then I think I'm building a great tool set.
I'm focusing on the fundamentals of design, and getting those right. I can focus on that because I'm not building a GUI. If I decide to start over in some part of the code to make it fundamentally better, I don't have to redo UI and window components. Having to do so would make me more likely to feel tied to a particular approach. Once the design is right, and if I have time and interest - I can add a GUI.
It’s awesome that someone is building something for MAC, someone has to take care of the MAC users, but again programming for MAC is like restore old cars, everyone love it but just few will use the service, basically you spend many hours on the software and because the target is MAC you collapse the target to the 5% of the general population, usually I look for 95% since I get more return for my bucks.
If the target is yourself then as long you are happy and makes your life easier then go all for it, it is an awesome sensation to create sequence with your own software, Also you mention Linux so the target may be is a tech user, if that is the case then be prepared to spend more time creating documentation than features, since tech user the first thing they go is for documentation.
First of all, MAC is an ethernet hardware address, Mac is a type of PC. You can tell from your post that you don't spend much time outside the win32 dev world. If you go to any tech conference where the brightest minds are working on the latest tech - you will see way more than %5 Macs there. This is not meant to be a Mac vs PC thing - that is long dead. But I'm writing software for people who are tech smart and sophisticated, and most of those are Unix/Mac people these days (just look at the recent Kinect hacking scene).
Mostly I'm writing this for myself. Second I'm writing it for script literate people who want to get into DIYC, third I'm writing it for DIYC people who want to take it to the next level while spending a fraction of the time working on sequencing.
Companies make specialized software and make a lot of sense for all platforms since on MAC or Linux is low volume high margin, but if the software is Open source what is the end benefit of it?
Hmm - vast majority of open source software is Unix based - so the above does not make sense.
Sorry if I sound too pessimist, I just want to make sure you have clear what are the reasons to create a new software, I may be missing something and I apologies if I didn’t understand your idea.
So may I ask, who is the target for the software you have in mind?
Cas.[/left]
To me writing my tools are about being nimble and flexible in creating sequences. I put up some sample code for creating a many-channeled RGB mega tree on another thread - I'm not sure how you could ever make something like that easy via a GUI:
http://diylightanimation.com/index.php?topic=3556.msg67939#msg67939
I know that we have some similarities in our programs - but I'm not trying to reach the most people, or sell it, etc. But I also have spent relatively little time on it and already have a lot of functionality considering I only started several weeks ago.
-Preston
-
I never put in doubt what the software can or can’t do, I made it very clear asking who the target user is, and as you mention you target a tech savvy so all the points I made did not apply, if you want then we can start over and comment about what I think for software that reach tech people.
I’m sorry if you took it personal, in a tech conference may be the brightest minds working on the latest tech, but I’m not targeting them, I’m targeting users in DLA which are in need of software to help them to create sequence easier and faster than current software, does GUI have to sacrifice some versatility… may be… who knows…, that’s the challenge, but even if has to sacrifice some and still provide way over more features than current software, then is mission accomplished.
From your response looks like you may think Prancer won’t be free, when in fact it will be.
Cas.
-
Guys it is not about who is making the right choices. It's about everyone making stuff their way. The users are always the people that decide what is popular in the end.
I do not want all three of you working on three programs all the same. Make it your program to the goals and specs you have in mind. Let the others do the same. In the end the users have lots of choice and they are happy and some will use one and some will use another etc.
It nevers bothers me to see someone use hardware other than mine. As long as you do it your way and it is useful to you. The other people that do use it will be the icing on the cake. You will get a great satasifaction from seeing them use it and enjoy it.
I think all have promise. If I had not been so busy getting a show together and helping users get Aether working in a hurry I would have by now setup the other two with forum areas.
It occured to me reading this thread that members may see three people working on Software but only one with an area. This is not to be taking as anything, Prancer was worked on first and so I had got an area setup. The other two I just had not got with them to see if they wanted one and what to call it.
That is being rectified.
RJ
-
Guys I never starting posting my ideas here to step on any one in any way.
I hope we can all peacefully coexist here, otherwise let me know and I will develop else where, I do have a few web sites of my own, or if the idea of new free software is what's bothering people, I can just keep the software to my self. Time permitting I will at least be making this program for my own personal use for next year, wether other people want me to releases it or use it that's up to the rest of you. Last thing I want to do is release a peace of free software that causes a split in the lighting community.
At the end of the day were all taking different approaches to sequencers.
castortiu - from what I understand Prancer will completely free the user from the gridv (there will be no grid at all), and be all Item based. It will also be set up so that that any one can pick it up and start using it.
ptone - hour ideas is scripted based and will be more for tech people and musicians.
My idea is a modern take on a grid based sequencer.
Maybe I am missing something, and if I am please let me know what it is, but I can't seam to figure out how any of our projects are steeping on each others projects.
-
Hi Csf,
IMHO
Please develop the program you want, no one has the right to say otherwise
Hopefully you and the other programmers develop the best program each can and let the users decide if they want to use it or not. Each program should state the intended level of user to use the program. ie: Easy, some scripting, heavy scripting, etc
Personally I love to see each and everyone's program here on DLA.
I think a lot of people who are normally nice and friendly are just stressed out.
Cheers
Rick R.
-
Guys I never starting posting my ideas here to step on any one in any way.
I hope we can all peacefully coexist here,
I thought that was what I was saying ? Maybe I did not come out well but I meant there is room for it all.
if the idea of new free software is what's bothering people
I did not know or see people bothered by it, the only people I see saying anything is the three that are developing and we all know you each will think yours is the best or you would not make it the way you plan to.
RJ
-
Just to be clear - I think more the merrier. I've learned what I have from diverse communities that share what they know and enjoy a bit of friendly challenge. I'm sorry if I come across a little bombastic at times, but I think what interests are shared by people working on new stuff is greater than that which is different.
Cas - I applaud you working on something anyone can use. Quite honestly the main reason I'm not, is that it is 10+ times more work than what I'm doing.
I think we should all of course keep on keeping on, and continue to share ideas and progress. When and where possible, we should collaborate on standards of interop. For example, should there be some new format other than vixen? For me I'm thinking of the signaling layer - which contains basic timing events and objects, but not full channel output.
RE RJ's comment about making it the best. Reminds me of a comment made by a friend who was a world class kayaker and kayak designer. I asked him once if he thought his designs were the best. He said - of course, If I didn't think they were the best, I would design them differently. He knew that not everyone would agree, but it was his passion and focus to his own ideals (sometimes quite counter to the industry) that led to the quality of his designs.
-Preston
-
RJ you have been very supportive to all of us and I appreciate it.
I was referring mostly to the post by castortiu. I can only imagine the work he has put in to Prancer and I am in no way trying to take away from his accomplishments. At the same time though I felt like his post was somewhat against the idea of other new software.
I have scene it go bad before in communities when someone is developing a software and then another programer comes in and has a different idea for a similar program, and next thing you know there is a split in the community. It happened in an open source game I was working on at one time. I was working with the original main programer of an open source game for a while, mostly testing, importing objects, making custom xml files for the game objects, creating GUI XML files, and trying get it to compile (the list of libraries were rather long and at the time I had made more progress then any one else on getting the code to compile) . Then all of a sudden a new programer came on the scene, at this point the original game was over two years in development and had a very strong code base (it was a completely custom game engine). This new programer started showing all these pretty screen shots. I will say the screen shots were nice, but the fundamental code that we already had laid out was not there, it was mostly all eye candy he was showing. Well the rest of the community started baking the new coder, and well the community split quit badly. Now it's been over a year and nether version game has made much progress at all. Truthfully that is the last thing I want to see happen here. Maybe that experience has just left me with a sour taste in my mouth since I spent all most four years involved in the effort see it fall apart.
Sorry for any miscommunication. Just being the newest person here I rather bow out now if it was going to be an issue for the community.
Personally I too feel the more the merrier, and that was the whole reason I started developing the ideas for this program, at the end of the day each user has there own things there looking for in a program, and the more programs they can pick from the better the chancres are they will find one that meats there needs.
-
I’m not continuing the discussion since everything I said was misinterpreted.
First I never say I was bothered at all because there are more software in development, in fact I applauded many times about people taking challenges, how that became I don’t like more people creating new software honestly I don’t know.
Prancer “quick updates” thread was hijacked and didn’t say a word since I thought was cool about more people bringing ideas.
Second, the whole intention of the post was an introduction to what I see is a limitation from “my point of view” and instead I wanted to start to give feedback how you could take a product/idea that will be used for few people and bring it to the masses, but of course before I could start to give feedback I was shoot in the head.
If you have 95% of DLA users using Windows and they do not have a degree in computer science then If you develop only for Mac and do scripting then you will have very few users and that’s a FACT, but if the goal is NOT to bring the application to the masses then it ok since was never the goal, that was the main reason of my question, but we/DLA are in need of new software to control thousand of channels and I think anyone spending time on new approaches should try to focus on bringing a solution to the problem with whatever approach, never I said that any new approach must contain a GUI, in fact Prancer is based on a pseudo language and the GUI is on top of it.
For example one of the problem is how in scripting you handle physical location, basic effects are done on a Megatree but what about I need to create an effect that is a chase with only color red and starts on the left of the display and finishes on the right, basically any object between should be scanned for red channels/pixels and turn on accordingly, if you do not contemplate physical location (X/Y/Z) in the original design then the application is already limited, a GUI allow you to do that since every object contain a physical location, but again the GUI is an artifact and the core should be who is already prepared for that. If you start just with the scripting then when the GUI layer is added you might find out that create those kind of effects won’t be supported unless the Core change radically. AGAIN I’m not saying that the GUI is mandatory, I’m just saying be sure what the final goal is and what are the step to reach it, and if in the process we can have updated working versions even better.
Also the MIDI approach is fantastic as a learning experience but who will use it? LSP approach is a good one, first they are capturing the users providing what the user expect, after people complain that is buggy, and slow, then they added MIDI and WII, and keep other set of users happy for another while until they start to solve the problems, may be the software is crap inside, but once they take the market they have time to fix everything over time.
I have experience in the whole software life cycle development and you can create a beautiful piece of software from the engineer point of view but be a total disaster on the average consumer and have a horrible written piece of software and capture 99% of the market, when I asked about who is the target is because if the application is intended to be used for DLA users then the approach as it is won’t work, maybe there is a way keeping the original ideas but give a nice wrapping and provide what people expect. If Prancer never sees the light of the day for x or y reason then other applications should be already trying to solve the problems as well, so we can have plan A, B and C.
From “my point of view” is like trying to shoot a fly with cannon.
But as Preston said, it is not made for the average Joe, so what I wrote above does not apply.
Having said that, I step aside…
Cas.
-
Prancer “quick updates” thread was hijacked and didn’t say a word since I thought was cool about more people bringing ideas.
Second, the whole intention of the post was an introduction to what I see is a limitation from “my point of view” and instead I wanted to start to give feedback how you could take a product/idea that will be used for few people and bring it to the masses, but of course before I could start to give feedback I was shoot in the head.
Cas,
Nobody is hijacking anything, and nobody is shooting you in the head <md..
We are all just exploring our interests and pursuing this because it is challenging and fun and rewarding at one or more levels. You continue to send some mixed messages about whether you are passing judgement on the value of these other projects, and part of it is that you are not a native English speaker. You feel strongly about the goals you have set out for the average DIY user/member running on win32 platform - so continue to channel those efforts. But continue to engage with your peers in discussions on the common challenges and solutions associated with the next wave of high-channel count setups, there is no right or wrong way here.
All the best,
-Preston
-
castortiu thank you for the expanded explanation. I fell I know have much better understanding of where you are coming from.
Prancer “quick updates” thread was hijacked and didn’t say a word since I thought was cool about more people bringing ideas.
Second, the whole intention of the post was an introduction to what I see is a limitation from “my point of view” and instead I wanted to start to give feedback how you could take a product/idea that will be used for few people and bring it to the masses, but of course before I could start to give feedback I was shoot in the head.
I am really sorry if you feel I shoot you in the head. I think ptone may of hit it on the head if you not a native english speaker. My writing skills are definitely far from an english major, and that may of lead to some confusion along with me being a bit confused about your original post.
Well know that I believe waters are cleared I hope we can all help each other and our programs along ;D Cause from my experience programs make the best alpha testers ;)
Edit: I see RJ set up a board for me, it's 2:15 am here now and I have a day of putting up lights ahead of me tomorrow so I better get some sleep, but tomorrow night I will put together a topic that lays out my ideas and plan so that you guys can all give me your feed back on them ;)
-
Hi Guys,
Just for the record. I use Windows, MAC, Linux (in no particularr order)
I have some programming background (mostly a hobby). Been using a computer since 1984.
I don't get into this OS is better than that OS. I see pros and cons to each and just use the best tool for the job.
To be honest, If I could use Linux Init 3 to run a sequence I would be thrilled (very little overhead). To program the sequence I would more like to see what its doing but a mix of gui and programming would good. My problem is I have no music background.
But then again I don't see myself as the average user.
Sorry for my rant
Cheers
Rick R.
-
Do you have instructions for loading xlights on linux. I am running Ubuntu and i would love to not have to swap out hard drives to windows just to run my show.
-
Do you have instructions for loading xlights on linux. I am running Ubuntu and i would love to not have to swap out hard drives to windows just to run my show.
You need to setup svn and get xlights here http://sourceforge.net/projects/xlights/develop
To install wxwidgets try here http://wiki.wxwidgets.org/Installing_and_configuring_under_Ubuntu
After much trial and error I was able to compile it in Debian
At the moment its really DIY software on Linux
Have fun and good luck
Rick R.
-
This is the current instructions for building xlights, its in the svn.
http://xlights.svn.sourceforge.net/viewvc/xlights/trunk/ToolConfig.txt?revision=52&view=markup (http://xlights.svn.sourceforge.net/viewvc/xlights/trunk/ToolConfig.txt?revision=52&view=markup)
-
Do you have instructions for loading xlights on linux. I am running Ubuntu and i would love to not have to swap out hard drives to windows just to run my show.
Have you tried Virtualbox to have a virtual windows machine on your Ubuntu computer?
I have a headless debian server with virtualbox running windows xp as my show computer. It works great
Cheers
Rick R.
-
Let me see if I've got this right...csf is recreating the grid as groups through MIDI, castortiu is doing a GUI for the masses, ptone is doing a python scripting language for the techies....
Man those all sound good to me....any thing but do all those channels with just a grid.
Any of you thought about putting it all together? A gui to do midi groups with a window to write a python script that would seamlessly integrate with the rest sounds like the best of all worlds!
And please, please, make your file structures interchangeable!
If the all together can't be done then at least I could use the GUI to make my shell of a show then use a keyboard to use outside to fix it all up and then write some scripts that would do what I couldn't do any other way!
In other words....Be nice...play well together, and write, write, write!!! I want it all! NOW....at least SOON!
Thank you all for all the effort.
Arvin
-
Let me see if I've got this right...csf is recreating the grid as groups through MIDI, castortiu is doing a GUI for the masses, ptone is doing a python scripting language for the techies....
Man those all sound good to me....any thing but do all those channels with just a grid.
Any of you thought about putting it all together? A gui to do midi groups with a window to write a python script that would seamlessly integrate with the rest sounds like the best of all worlds!
And please, please, make your file structures interchangeable!
If the all together can't be done then at least I could use the GUI to make my shell of a show then use a keyboard to use outside to fix it all up and then write some scripts that would do what I couldn't do any other way!
In other words....Be nice...play well together, and write, write, write!!! I want it all! NOW....at least SOON!
Thank you all for all the effort.
Arvin
I agree is all is very exciting, check out the video of Prancer if you have not scene it yet, looks really great.
One thing I believe you got wrong though is my program has no plan for MIDI right now, thats ptone's scripting program program.
Right now Prancer is exporting to vixen and xlights supports vixin files. So there should be no issue between Prancer, Vixen, and Xlights.
As far as for ptone's scripting program program I am not sure if it will export files of actually timings / channels. Or if the scripts them selves will be the actually files, generating all the lights on the fly.
-
Hi Guys,
Is there a cheat sheet or examples of scripts besides the default one?
Thanks
Rick R.
Sorry I met to post this in Xlights topic <fp.
-
There are 8 test scripts in here that may help you understand mini basic
http://xlights.svn.sourceforge.net/viewvc/xlights/trunk/UnitTests/basic/ (http://xlights.svn.sourceforge.net/viewvc/xlights/trunk/UnitTests/basic/)
-
Basic, really, basic. There are so many choices out there, just surprised you'd pick something that still has "GOTO 2000" in these times. One of the sample scripts is the lunar lander program written in the mid 70's.
Well, I'm sure the interpreter was drop in simple, and it looks like you are only using scripting for basic playlist tweaking - but please don't let BASIC become the powertool for xlights.
-Preston
-
Basic, really, basic. There are so many choices out there, just surprised you'd pick something that still has "GOTO 2000" in these times. One of the sample scripts is the lunar lander program written in the mid 70's.
Well, I'm sure the interpreter was drop in simple, and it looks like you are only using scripting for basic playlist tweaking - but please don't let BASIC become the powertool for xlights.
-Preston
I was a little taken back by it. I haven't seen line numbers in basic for a LOOONG time
Cheers
Rick R.
-
We wanted to make scripting as easy as possible to people that may not necessarily be programmers, and though this was a really good way to go.
Now that being said right now scripts are not designed to give xlights new big features, but to give the user a way to access features already in the program.
Such as in the scheduler, the scheduler is not run by scripts but the scripts can be used to do minor tings with the scheduler that we did not program in to the main scheduler. Like script wizard were the first or last song is only played once.
Being open source, and really only relying on wxwidgits for any external libraries makes it easy enough that most people with some programing experience can probably modify the actually program fairly easily to add a big new feature.
Now maybe in other parts of the program we will find that the scripting engine is not advanced, or faster enough for what we want it to do and will have to use some thing else. But I think we will cross that bridge if / when we get to it.
Do you guys see the basic scripts as being easier for none coders to pick up as compared to some thing like python? Do you see any other issues that may arise besieds for possibly speed that we are not seeing?
-
Hi Csf,
To be honest I am not a python user but it would seem more up to date than mini basic. I looked at a few beginner python scripts and it was easy enough for me to understand.
So far xlights is doing what I need (hoping the future versions add some features), just my opinion that while easy, mini basic just seems backwards and dated.
Maybe a poll showing a mini basic example and python example and ask the users. Just make the examples do the same thing and be about light or channel example, ie: turning channel 1 on or first seq in the list, something like that.
Good/Bad idea?
Thanks
Rick R.
-
I am open to suggestions, I will start a new thread to capture everyone's input.
Matt
-
I know a few people where interested in helping with coding new features for xLights.
I have started to come up with a list of features to implement and some of the data structures needed to drive the features.
If I was to post up some of the data structure layouts / what need to be accomplished for a new feature would any one be wiling to start coding them?
Or am I better off stating to cod them my self, document the code, and then you guys will jump in where you would like.
Right now I am particularly thinking about the virtual channel support since I have it fully laid out and am ready to start coding it. Also it needs to be done first since every thing else will build on top of it.
If some one wants to code the virtual channels then once I have them on there way I can start working on the groups, and then if some one else wanted to work on groups, I can start working on effects, and we can just continue the pattern until all coders are busy working on things.
-
I have very limited programming skills but I would like to volunteer to beta test if needed.
Cheers
Rick R.
-
Right now I am particularly thinking about the virtual channel support since I have it fully laid out and am ready to start coding it. Also it needs to be done first since every thing else will build on top of it.
If some one wants to code the virtual channels then once I have them on there way I can start working on the groups, and then if some one else wanted to work on groups, I can start working on effects, and we can just continue the pattern until all coders are busy working on things.
Just to clarify the platform, this is all C++ and wxwidgets correct?
I'm probably only able to contribute to architectural design decisions, being a interpreter bound guy - but a lot of the architectural challenges would be similar to what I've just been through, going through. I can read the code, or just an outline in pseudocode.
-Preston
-
Hey csf,
I think we need to see some architectural representations of what you are thinking in order to see if we can get started on breaking this up into pieces. Do you have a high level design sketch or an object model in mind? Are you planning on doing some inheritance in the object model to define different but derived objects? If we can get on the same page about these types of things then I would be glad to pick something up and start coding.
The challenges is we need to have some coherent design to march to so that we can make sure we are coding towards the end goal.
just my $.02
I will note that most of my experience is in embedded systems using C and a RTOS so I am not the best person to be giving OO advice...
I should be able to put in some good time on coding in the next two weeks or so if there is a design that I can focus on.
Frank
-
I just sent this to Frank in response to an email he sent me, but I think it may help give some of the tech people in our community a better idea of what I am trying to accomplish, so I will post it here too.
Right now Xlights suports Networks, Each network has a type, port number, bud rate, an number of channels.
Virtual channels will build on top of networks. It will assign physical channels to virtual channels, which will be used in side the program. This will allow users to remap the channel used inside the sequences to there physical channel in there display set up. Basically no more having to worry abut plunging things in to the wrong channels on set up. Also lets say a channel goes bad in your show, all you would have to do is remap to a free chanels and you would be good to go.
A virtual channel object would look some thing like this
channel Id = unique integer used internally inside the program for identifying the virtual channel
channel name = string user can create to identify channel inside groups
Network type = integer that corresponds to net work number set up previously.
channel number = integer that represents what channel in the network the virtual channel is.
Then there will be two types of groups.
Groups of channel objects.
For RGB lighting you can assign a color to one of these groups.
Groups of Groups.
So for an RGB flood light you can asinine one virtual channel to red, one to green, and one to blue. Then assign all three groups to a group of groups. (now I will admit this may seam like a bit of extra work for a single flood but for RGB pixel nodes, or light matrices, I think the extra set up work is the best way to go, epically since we can automate some of the set up work)
Now you have effects.
Originally I was thinking that effects pass parameters back to groups and the groups do there work. This Idea was created to keep effect scripts easier for users to create.
Right now effects have switched to having a group passed over to the effect and the effect processing the group data and telling the program what to do. This should allow for much more powerful effects, and will eliminate the issues my original idea ran in to when dealing with smart string mega tress or light matrix. Basically the original concept failed when it wen it went in to two dimensions. So for now I have decided that effects will all be hard coded in to the program, until I can come up with a good way to integrate the effects with a scripting language.
The one issue that I can see right now is what exactly does the effect tell the program? This I fell depends on if your ruining a live show from like a console or a scheduled show. If its a live show the program may well just pass the commands right to the light controller dll. If the show is going to be shown in the future I see storing all the actual lighting commands needed (to there virtual channels) to a 2demensional array where each row is a virtual channel and each column is a time in which the commands change. So I think efects should send the data to a special class / function that will minipulate the data as neded depending on if the show is live or being scheduled.
Right now there are 4 pieces to xlights.
menu = sets up networks
scheduler = runs shows
tester = test networks and hardware
library for controlling lights.
Virtual channels will be part of menu
My original idea was to add two more programs
Console = run a live light show, create groups, create effects
Sequencer = organize groups and effects on a time line set to music
At this time I am wondering if with the change in effects if it may be worth just crating every thing in side the sequencer and maybe make a console at a latter time when the sequencer is complete, instead of making the console first.
So right now if I wanted to turn group one on I would do this
Pass group1 to effect on, effect on will give the commands to the method for determining what to do with the comands, if its in save mode it will just store the commands in the array I described above, if its in live mode, it will read the data of that virtual channel, then read the network data for that channel and pass the corect comand to the light library and the lights will respond to the command.
-
I just sent this to Frank in response to an email he sent me, but I think it may help give some of the tech people in our community a better idea of what I am trying to accomplish, so I will post it here too.
thanks for keeping the discussion out in the open. While I may sound challenging at times, clarifying my own thoughts on this has helped me already make some improvements to my own program - which over break I hope to get in a releasable state.
Right now Xlights suports Networks, Each network has a type, port number, bud rate, an number of channels.
Virtual channels will build on top of networks. It will assign physical channels to virtual channels, which will be used in side the program. This will allow users to remap the channel used inside the sequences to there physical channel in there display set up. Basically no more having to worry abut plunging things in to the wrong channels on set up. Also lets say a channel goes bad in your show, all you would have to do is remap to a free chanels and you would be good to go.
A virtual channel object would look some thing like this
channel Id = unique integer used internally inside the program for identifying the virtual channel
channel name = string user can create to identify channel inside groups
Network type = integer that corresponds to net work number set up previously.
channel number = integer that represents what channel in the network the virtual channel is.
IMHO abstracting a "virtual" channel to a single physical channel doesn't add enough value for the effort. Take an RGB node. This will always be constrained to 3 adjacent channels. So to map Red Green and Blue each to their own virtual channel seems expensive.
Instead abstracting the light entity with a "start channel" property would yield more return. This becomes the object which you attach sequencing events to, and can be "remapped" to a different start channel.
Then there will be two types of groups.
Groups of channel objects.
For RGB lighting you can assign a color to one of these groups.
Groups of Groups.
So for an RGB flood light you can asinine one virtual channel to red, one to green, and one to blue. Then assign all three groups to a group of groups. (now I will admit this may seam like a bit of extra work for a single flood but for RGB pixel nodes, or light matrices, I think the extra set up work is the best way to go, epically since we can automate some of the set up work)
Do I understand that you mean to map things out like:
flood group
red group
red virtual channel
red physical channel
green group
green virtual channel
green physical channel
blue group
blue virtual channel
blue physical channel
I agree that a little extra work up front is often worth it - but I'm failing to see what each layer there gives you.
Now you have effects.
Originally I was thinking that effects pass parameters back to groups and the groups do there work. This Idea was created to keep effect scripts easier for users to create.
Right now effects have switched to having a group passed over to the effect and the effect processing the group data and telling the program what to do. This should allow for much more powerful effects, and will eliminate the issues my original idea ran in to when dealing with smart string mega tress or light matrix. Basically the original concept failed when it wen it went in to two dimensions. So for now I have decided that effects will all be hard coded in to the program, until I can come up with a good way to integrate the effects with a scripting language.
The one issue that I can see right now is what exactly does the effect tell the program?
I'm assuming your program will have a runloop of some sort. The question you will have to answer is who is responsible for ultimately determining a channel value. Is it the virtual channel group, or the effect. If the latter, the problem is managing the handoff of "ownership" of the virtual channel between effects, or between effects and a bare virtual channel. I'd argue that it should be the thing that is closer to the virtual channel. In this case an effect acts as a choreographer. This also allows effects to be overlaid and use different blending styles (ala photoshop). I'm working on a demo of some new features in my code that allows this overlay. For example you can have a "pulse" effects (ramp up and down in intensity, color etc) a strobe effect applied simultaneously. So you have a light that is dimming in a pulse, changing hue in a pulse, and flickering all at the same time. In such a scenario no one effect can tell the channel what to do, but each can "alter" various properties for an element (with a blend mode), and the runloop cycles through each element asking for their channel values.
This I fell depends on if your ruining a live show from like a console or a scheduled show. If its a live show the program may well just pass the commands right to the light controller dll. If the show is going to be shown in the future I see storing all the actual lighting commands needed (to there virtual channels) to a 2demensional array where each row is a virtual channel and each column is a time in which the commands change. So I think efects should send the data to a special class / function that will minipulate the data as neded depending on if the show is live or being scheduled.
You might be interested in this thread where we are talking about the pros/cons of vixen as a universal interchange format:
http://doityourselfchristmas.com/forums/showthread.php?p=140547
Right now there are 4 pieces to xlights.
menu = sets up networks
scheduler = runs shows
tester = test networks and hardware
library for controlling lights.
Virtual channels will be part of menu
My original idea was to add two more programs
Console = run a live light show, create groups, create effects
Sequencer = organize groups and effects on a time line set to music
I know you are pretty wedded to the idea of this being an integrated component - but I would love to see xlights be a lean mean hardware interface/lighting network configuration layer, with an API, and your project (and mine, and prancer) be clients of that API that send lighting control data. I don't think I'm going to get very far with that suggestion though ;-)
So right now if I wanted to turn group one on I would do this
Pass group1 to effect on, effect on will give the commands to the method for determining what to do with the comands, if its in save mode it will just store the commands in the array I described above, if its in live mode, it will read the data of that virtual channel, then read the network data for that channel and pass the corect comand to the light library and the lights will respond to the command.
that's a lot of commands ;-)
I'm not entirely sure, but I think the bit about "give the commands to the method for determining what to do with the comands" implies a certain amount of abstraction of the triggering event. I went ahead and banged out this schematic of how my program is involved - briefly:
events are what drive the show. These events are either trigger events (which consist of a on and off time and an intensity) and map events (which can be wired up to various properties). Events control elements. These elements may be a single light element, or a group, or chase etc (effects are not shown here, but they would basically be elements as well). The element is then responsible for determining what the value of each of its channels should be.
The idea is to have the events layer be general and expressive of the timing. The elements handle the complexity of translating that into raw channel data.
-Preston
-
thanks for keeping the discussion out in the open. While I may sound challenging at times, clarifying my own thoughts on this has helped me already make some improvements to my own program - which over break I hope to get in a releasable state.
I definitely think the more open the better. We have quite a few talented people all trying to solve the same problems, and I fell we can all help each other develop better programs.
I know you are pretty wedded to the idea of this being an integrated component - but I would love to see xlights be a lean mean hardware interface/lighting network configuration layer, with an API, and your project (and mine, and prancer) be clients of that API that send lighting control data. I don't think I'm going to get very far with that suggestion though ;-)
Well we already have the library for controlling the lights. So its sort of an API.
This is definitely an interesting idea, I would be interested in hearing Matt's view on this.
If we did do something like this there are a few things to consider.
Should virtual channels still be integrated in to xlights? I would say yes because the mapping stile effects sequences.
Now lets say I make my own program separate of xlights, if I want to control lights with in side the sequencer, or I want to make a console then ether my program needs to be installed along side xlights and the the user needs to set up the proper dependencies.
Then what ever I develop will be done cross platform with wx widgets and C++
Now since a console or a sequencer will be separate exe's inside xlights does it really make the program have that much more wait on a system. The resources needed will depend on what programs you load.
I would be open to the idea of separating the programs, but I just want to make sure that it would truly make sense to do so.
IMHO abstracting a "virtual" channel to a single physical channel doesn't add enough value for the effort. Take an RGB node. This will always be constrained to 3 adjacent channels. So to map Red Green and Blue each to their own virtual channel seems expensive.
Instead abstracting the light entity with a "start channel" property would yield more return. This becomes the object which you attach sequencing events to, and can be "remapped" to a different start channel.
While I agree that for RGB nodes there needs to be some automation on the mappings / remapping, no one wants to do 6,000 channels by hand.
But if we make RGB nodes as part of the architecture of the program I fell we are making things less fixable. I know some people have RGBW Lights in there display. I have heard of some one doing RGBWY lights in there display. I have items of my display that are RGWC.
What if a node system comes out that has a different channels configuration then 123, 456, 789, and so on?
This is why I feel a channel should be a channel and a group makes up a device.
Do I understand that you mean to map things out like:
flood group
red group
red virtual channel
red physical channel
green group
green virtual channel
green physical channel
blue group
blue virtual channel
blue physical channel
I agree that a little extra work up front is often worth it - but I'm failing to see what each layer there gives you.
For an RGB flood there is not much it gives but lets look at a smart string mega tree
Group = the entire tree
group = one smart string
red group
all red virtual channel in the smart string
green group
all green virtual channel in the smart string
blue group
all blue virtual channel in the smart string
group = next smart string
red group
all red virtual channel in the smart string
green group
all green virtual channel in the smart string
blue group
all blue virtual channel in the smart string
Now you can assign commands to each smart string and to each node in the smart sting.
I have to get to a final I will type up more latter.
-
I think I hit basically every thing major before now that I look it back over.
Another idea is we can see what software ptone creates. We can see how much work it would take to get it working with xlights and to be cross platform, and then take it from there trying to create an interface for it and so on.
This could be a viable option as long as ptone is okay with the idea, and the program will function in a way we can build off of.
Then again if we do create a mix of xlights and ptone somewhere does it become its own separate program? Guess it depends on if there are so many changes that it will slow down xlights or the core of ptone software, which would then make it better being it's own thing.
Overall there are allot of unknowns but it may be worth something to consider.
I think the first thing we need to figure out is will xlights just be for light control or will it have every thing in it needed to make a show.
Maybe we should schedule a chat to talk about these ideas.
-
I think I hit basically every thing major before now that I look it back over.
Another idea is we can see what software ptone creates. We can see how much work it would take to get it working with xlights and to be cross platform, and then take it from there trying to create an interface for it and so on.
This could be a viable option as long as ptone is okay with the idea, and the program will function in a way we can build off of.
It's too early to say - but I think the challenge of new sequencing software will require several different approaches for different audiences. Cas said he wants Prancer to be good for the average Joe running on windows gear. I'd say my primary target user is me ;-) (and others who might think like me) and I'm trying to come up with some neat layers that sit between a trigger, and a bunch of channels.
I'm sure either a web front end (for local or remote use) or a wxPython UI could be grafted on at some point, but I would want to get the core right first.
I spent a little time trying to learn the internals of xLights - and I still think a great area of focus for the project would be to take the bulk of xlights_out.cpp and wrap it into a libxlights library that could be linked to from other software, or be used in dynamic language bindings.
Having this idea of a rosetta stone library I think is very appealing, and is something any sequencing or light control software project of the future could make use of. xLights would then use this libxlights library itself much the way it uses xlights_out.cpp internally and statically to provide a timing UI etc. But people might come up with other scheduling or testing UIs that take advantage of the core lib.
I think the first thing we need to figure out is will xlights just be for light control or will it have every thing in it needed to make a show.
IMHO - the best things are those that focus on a limited domain, and do it very well. When something tries to include everything and the kitchen sink - it feels bloated, confusing and ineffective.
-Preston