DiyLightAnimation
Software => xlights => Topic started by: dowdybrown on January 11, 2012,
-
I've been thinking a lot about where to take xLights next and I need feedback from the group.
In your reply, please RANK the features you would like to see from most important to least. Or if you like xLights just the way it is, no more changes, please state that. Justifications and constructive criticism are always welcome. As with any free software, there are no guarantees, but this will help prioritize my time. You may include in your list any of the items below, or feel free to add others (as long as you perceive the time investment to be modest).
So here are some possibilities I've thought of, in no particular order:
1) Updated Mac version - the version on SourceForge is way out of date. I have been working on this one, but have run into some bugs that I haven't been able to solve yet. If you vote for this one, would you be ok if the updated version was for Intel-based Macs only?
2) A compiled Linux version. Please specify which version of Linux if you pick this one.
3) Merge the Scheduler and Tester programs so that you can run tests while your show is waiting to run (currently you have to exit the scheduler to run tests).
4) Create an iPhone/iPad/iPod touch version of the Tester program. This would be E1.31 ONLY - so only compatible with the Etherdongle, ECG devices, and some of the projects on DIYC.
5) Create an Android version of the Tester program. This would be E1.31 ONLY - so only compatible with the Etherdongle, ECG devices, and some of the projects on DIYC.
6) Add startup parameters to the scheduler, so you could invoke it from the command line or from the Windows scheduler and have it play a particular playlist for a specified duration. The GUI would still be displayed, but you could give it direction on what to do via the parameters.
7) Since LOR controllers, and now D-Light controllers, speak DMX, I would like to remove support for the LOR and D-Light protocols. People with these controllers would have to run them in DMX mode. Even though people might bemoan the lack of flexibility, I think they will really like the improved responsiveness (i.e. no lag) in their shows. Secondly, if we take this step, then I can simplify the scheduler to only play xLights sequence files. LOR and Vixen sequences would need to be run through the xLights converter. This would make the xLights coding much simpler (I vote for this one :) )
8 ) Support for DMX Universes in LOR sequences (e.g. in S3, you select Insert Device, then select DMX Universe). I am going to do this one anyway.
9) Add support for LSP sequences in the xLights converter.
10) Display real channel names in the Tester, instead of "Channel 123".
11) Create a program to display, and possibly make simple modifications to, an xLights sequence file.
Please note that I think it is highly unlikely that xLights will support Vixen 3.0 sequences in 2012, unless Vixen 3.0 includes some sort of export to Vixen 2.1 format. Well there you have it. I look forward to reading your responses.
Matt
-
#8, #10, #9, #7 (can live with), #4 (optional, nice to have, since I have an iphone)
And voting for #12 and #13 if possible ... and really those were a couple of my favorite things I could do in LOR that I can't do in xlights.
I'm not so much in favor of #7, but could live with it and understand why.
I"m not interested in the other options much ... and worry about your ability to support
all those platforms over time ... not sure you'd want to go there for your own sanity.
I'd like to keep xlights as small and simple as possible.
12) A 'Show on Demand' or 'Sequence on Demand' feature would be nice ... meaning it could queue up a show or sequence "on demand" ... then resume normal schedule thereafter.
13) Maybe a check box to 'Disable Schedule after end of current schedule / aka Graceful show shutdown' or 'after end of current sequence'.
-
First... I haven't said this enough -- but xLights is a GREAT program, great features, rock-solid, and I can't imagine how my show could have happened without this program. THANKS!!
With the ability to execute external commands from within the tool, this is less important. BUT, I would still be interested in creating web pages as a front end to xLights -- that I could offer to my viewers as the ability to select songs -- a jukebox. So starting a song from the command-line would be valuable for that reason.
6) Add startup parameters to the scheduler, so you could invoke it from the command line or from the Windows scheduler and have it play a particular playlist for a specified duration. The GUI would still be displayed, but you could give it direction on what to do via the parameters.
I'm interested in switching to Linux -- possibly -- but I can build for myself. Still my favorite distribution(s) are RedHat and Fedora... being able to build without making code changes would be great. With full Linux support available, I'd likely implement the web-based front-end (described above).
2) A compiled Linux version. Please specify which version of Linux if you pick this one.
I like this!! BUT don't forget to offer us a way to map channels to specific ports, like the python script created by Frankr. I'd guess the info should be available from LSP2 to allow this mapping step to be avoided altogether!
9) Add support for LSP sequences in the xLights converter.
Very helpful!!
10) Display real channel names in the Tester, instead of "Channel 123".
I use an android phone and prefer Android because its always with me.
5) Create an Android version of the Tester program. This would be E1.31 ONLY - so only compatible with the Etherdongle, ECG devices, and some of the projects on DIYC.
I like this one.
3) Merge the Scheduler and Tester programs so that you can run tests while your show is waiting to run (currently you have to exit the scheduler to run tests).
I like this!
11) Create a program to display, and possibly make simple modifications to, an xLights sequence file.
I have iPods, and would like this.
4) Create an iPhone/iPad/iPod touch version of the Tester program. This would be E1.31 ONLY - so only compatible with the Etherdongle, ECG devices, and some of the projects on DIYC.
An item not on your list:
14) The List-Selection controls in the GUI are awkward, and I suggest they could use refinement. Selecting an item -- without a visible indication that it is selected -- causes me to be confused everytime.
Another thing that I'd recommend for xLights and LSP2 alike...
15) run the code through some source code analyzers (multiple if you can find them). Getting results from Coverity, Fortify, or a good lint-like tool might uncover some anomalies and might even make the code more portable. I am not aware of problems with xLights :) but LSP2 could surely benefit from Purify, BoundsChecker, or some other tool to help find memory leaks.
I agree with taybrynn's input...
Yes. xLights does not need code bloat. If offering new features, maybe breaking it up into multiple/separate tools would be better. A scheduler, a player, a converter, a configurator, ...
I'd like to keep xlights as small and simple as possible.
I like this
12) A 'Show on Demand' or 'Sequence on Demand' feature would be nice ... meaning it could queue up a show or sequence "on demand" ... then resume normal schedule thereafter.
I like this too!
13) Maybe a check box to 'Disable Schedule after end of current schedule / aka Graceful show shutdown' or 'after end of current sequence'.
========================= My cut line... :) ============================
I'm leaving S3 behind for LSP2, so LOR features are not important to me now... I expect disappointment from the community if LOR is not fully supported.
8 ) Support for DMX Universes in LOR sequences (e.g. in S3, you select Insert Device, then select DMX Universe). I am going to do this one anyway.
It won't bother me... but I expect disappointment from the community on this too.
Please note that I think it is highly unlikely that xLights will support Vixen 3.0 sequences in 2012, unless Vixen 3.0 includes some sort of export to Vixen 2.1 format. Well there you have it. I look forward to reading your responses.
I liked having native LOR support, and hate to see it go. Still, I've sold my LOR controllers -- in favor of new LEs, leaving me with only 2 CCRs. I could part with the the CCRs if I find a move to CCR/DMX is a problem for me.
7) Since LOR controllers, and now D-Light controllers, speak DMX, I would like to remove support for the LOR and D-Light protocols. People with these controllers would have to run them in DMX mode. Even though people might bemoan the lack of flexibility, I think they will really like the improved responsiveness (i.e. no lag) in their shows. Secondly, if we take this step, then I can simplify the scheduler to only play xLights sequence files. LOR and Vixen sequences would need to be run through the xLights converter. This would make the xLights coding much simpler (I vote for this one :) )
I don't use Mac, so this is automatically at the bottom.
1) Updated Mac version - the version on SourceForge is way out of date. I have been working on this one, but have run into some bugs that I haven't been able to solve yet. If you vote for this one, would you be ok if the updated version was for Intel-based Macs only?
-
#9 LSP support. Since I'm an LSP and had a heck of a time with LSP scheduler sinceV2 came out couldn't run on last years show computer. I know David is working on fixes but since I'm looking at the Lynx conductor as the next step to get the computer out of the loop and it looks like xlights is going to be running the scheduler I don't want to have convert from one software to another and loose some date or timing in between conversions. I tried to covert some of my sequences some transferred OK others had a lot of problems in the conversion process.
#3 would be a great tool as things to go wrong or you want to try different things before the show starts so you can make changes later.
#6again a very nice option to have.
#10 makes ti a lot easier for the user so you don't have to remember what is what.
#11 A good option to have so you can make those small tweeks in between shows.
If you could do it live while the show is going on that would be great. This would allow you to makes tweeks after the sequence is played and if xlights would pick up the new version net time around then see the changes that you made.
-
6,5,11,12,13,15,2,4
I would elaborate, however the other two seem to have covered the bases nicely. I plan on ubuntu linux, or perhaps bsd. I use an android phone, and love the jukebox concept, especially phone driven, even better, merged with the queue next then resume program function.
-Rimist
-
9 and 10 are the only things on that list I would really want. The rest don't think would apply to me all that much.
-
#10,#11 and #6 in no particular order
#2 - Excellent option, I would not necessarily lock this to a particular distribution, as you will constantly be hounded for ports to other distributions. Instead, build the typical Linux Autoconfigure/Automake script and have the user build it. Once this is in place, you could look at having it picked up by some of the popular distributions.
-
9) Add support for LSP sequences in the xLights converter
10) Display real channel names in the Tester, instead of "Channel 123".
5) Create an Android version of the Tester program
11) Create a program to display, and possibly make simple modifications to, an xLights sequence file.
It may be a moot point as I hope to use a conductor if released this year but a backup plan is always good. I couldn't use the new format this year as some of my sequences the channels would act funky and #9 would probably fix that. #11 would have been a real help also. Both mobile phone testers would save a lot of time and running back and forth. I think I will have to figure out how to do #7 anyway for the conductor and I think I remember taybrynn trying it out and giving it a thumbs up. However it would be a problem for those who don't have a DMX dongle.
-
I would still like to see the ability to save a configuration file (actually multiples) in the tester. Hard to test RGB stuff in hybrid mode without having to go and uncheck the first 3 nodes of every controller and have to do it every time I start the tester.
-
#9
#10
#3
#6
#5 and or #4 Now have an Android but could allways change back to Iphone.
I also like taybrynns additional changes.
12) A 'Show on Demand' or 'Sequence on Demand' feature would be nice ... meaning it could queue up a show or sequence "on demand" ... then resume normal schedule thereafter.
13) Maybe a check box to 'Disable Schedule after end of current schedule / aka Graceful show shutdown' or 'after end of current sequence'.
Tom
-
10) Display real channel names in the Tester, instead of "Channel 123".
5) Create an Android version of the Tester program.
3) Merge the Scheduler and Tester programs
11) Create a program to display, and possibly make simple modifications to, an xLights sequence file.
and taybrynn's great ideas
13) Maybe a check box to 'Disable Schedule after end of current schedule
12) A 'Show on Demand' or 'Sequence on Demand' feature would be nice
"Please note that I think it is highly unlikely that xLights will support Vixen 3.0 sequences in 2012"
As is looks like I will be using Vixen 3.0 this year, this is Very sad news but understandable at this time.
and THANKS for a GREAT program.
-Jeff
-
#9, could even go with #7 and have LSP sequences be required to be ran through the xlights converter.
-
#6,7,8,9,10,& 11 for me :-)
thanks !!
-
Hi Matt,
1) "Mac Version" = Intel-base is fine with me - Not a top priority for me, windows or linux works.
2) "Linux Version" = Debian
3) "Scheduler and Tester combine" = Great, I do have issues with xTester and E1.31 where some strings light up and others don't. So looking for a easier way to "Select All" for E1.31 and then later unselect channels I don't want and I agree with jnealand about save selection.
4) "Apple IOS Tester" = Awesome, Yes
10) "Display real channel names" = Yes
For whats it worth. Moving forward to the conductor, I am thinking the tester will remain important but the scheduler will take a back seat. Now for the folks that don't use the conductor than I see xScheduler very much needed. My show would not of ran this year if not for the file conversion to xseq and I was only sending out 1260 channels.
Many thanks for all of your hard work and giving us the tools to test and run our shows.
Rick R.
-
An option I don't see on your list that would be very helpful:
A more laid out scheduler. One of the features I like on vixen is the ability to schedule routines, weeks in advance, and have them only run on certain nights. I could have one routine run at midnight for new years only. With xlights, I had to re-schedule my sequences the week before new years.
-
Would it be possible to give David @ LSP the required information so that LSP could export directly into xlights or conductor format?
-
The older version of xLights used a calendar scheduler. You could set the start and end time of you show each day but it only allow for one show per day. Maybe a combination and or option of scheduler layouts would be useful. Like you can choose the current week scheduler or switch it over to the Month scheduler (like your email client).
Rick R.
-
5, 9,10, 11 and Taybrynn 13. 8 is moot if you are going to do it anyway. AND Rick's Suggestion above.
-
1) Mac version YES, Intel only I can live with if that help solves issues. As far as versions of the Mac OS just keep it compatible with Leopard, Snow Leopard and Lion so older hardware can be used.
2) If others want it I for it.
3) Would be a nice feature but I'd rather see an IOS app, OK I guess the Android users as well, that allows you to take control of the entire system. Being able to shutdown a playing song, make changes to the schedule and run tests would be a nice feature. Also the ability to take a set of channels off line if they are failing. I'd have the IOS app talk to the scheduler rather then the controllers directly. If you can I'd love to see this work across the Internet maybe taking a feed from a web cam so you can see what's going on but local only is just fine.
4) See #3
5) See #3
6) Why not, it should be a really easy thing to do since you get the command line information from the Host OS anyway.
7) I can totally accept doing this. Should be no change to anyones sequences.
8) Agree
9) Totally agree.
10) Makes total sense.
11) That makes sense if you moving toward your own sequences in the future.
A while back I put my suggestion in for a third mode and that's LOR to DMX translation tables in xlights. I've been thinking about this and think what should be done is creating a table driven version of the translator that allows total control over how LOR sequence controllers and channels get mapped to xlights. Same for the other sequencers.
LOR controller channels would also not be limited to 16 but could have the full 512 channels available so one could write LOR sequences where a LOR controller would equal one DMX universe. This way you don't need the advanced version just to directly map DMX inside of S3. It's almost like a whole bunch of iDMX modules but with complete abilities on all channels unlike iDMX.
Using the table any LOR controller/channel could be mapped to any DMX channel. This allows one to import sequences from others and remap them to their own channel mappings.
An nice optional feature of the translator could be the ability to not only create an xlights file but also a remapped LOR sequences to make future editing easier. Multiple translation file would be allowed you just select the one you want and then translate. So if you have Richard Holdman's sequences you would have a Richard Holdman translation table. If you had sequences from someone else you would have a table for them. Later you could even add RGB translation into the mix to make moving from colored lights to RGB lights easier.
One future feature would be the ability to run more than one video display. Not an issue currently as I don't think any of the sequencers support more than one anyway but I'm sure it will happen. Just leave in the hooks for the future.
For windows and the Mac the ability to use their own calendars to start shows.
If you want to brain storm I'm available. It's one of my engineering strong points and what I've done at the last several places I've worked.
-
My first and biggest suggestion!! - 8 ) Support for DMX Universes in LOR sequences
4) Create an iPhone/iPad/iPod touch version of the Tester program.
10) Display real channel names in the Tester, instead of "Channel 123". It would be great if this would work on the iphone app too.
I would like to discourage this one.
7) Since LOR controllers, and now D-Light controllers, speak DMX, I would like to remove support for the LOR and D-Light protocols. People with these controllers would have to run them in DMX mode. Even though people might bemoan the lack of flexibility, I think they will really like the improved responsiveness (i.e. no lag) in their shows. Secondly, if we take this step, then I can simplify the scheduler to only play xLights sequence files. LOR and Vixen sequences would need to be run through the xLights converter. This would make the xLights coding much simpler (I vote for this one :) )
While I understand the appeal to have a single sequence file support, I regularly alter my sequences. I love the ability to change my sequences any time I want and xlights just continues to play them without having to go thru a conversion process.
Thank you for your committment to this hobby!!
Carey
-
The other thing I will mentioned with item#7 ... is that I have some sequences, maybe 30-40% of them, where the xlights .xseq file is actually way BIGGER than the .lms file ... I'm not sure playing back those larger files is helpful, but I'm also not sure why the conversion actually makes some sequences bigger, which in other instances, can make the sequence 1/3 the size.
I do think that if xlights supported the LOR DMX universe, it could make things on the LOR side a lot easier ... because building out 16ch controllers, while simple ... is time consuming for many to do.
I generated the XML myself and just threw it into the LOR config file, because there was no way I was going to manually build 256 16ch controllers and then label all those channels manually.
At this point, I still think generating XML is the easiest way to add stuff to the LOR config file, so that could be a candidate for a utility program.
-
The other thing I will mentioned with item#7 ... is that I have some sequences, maybe 30-40% of them, where the xlights .xseq file is actually way BIGGER than the .lms file ... I'm not sure playing back those larger files is helpful, but I'm also not sure why the conversion actually makes some sequences bigger, which in other instances, can make the sequence 1/3 the size.
I do think that if xlights supported the LOR DMX universe, it could make things on the LOR side a lot easier ... because building out 16ch controllers, while simple ... is time consuming for many to do.
I generated the XML myself and just threw it into the LOR config file, because there was no way I was going to manually build 256 16ch controllers and then label all those channels manually.
At this point, I still think generating XML is the easiest way to add stuff to the LOR config file, so that could be a candidate for a utility program.
I was looking at that this morning and was wondering the same thing. Matt uses the LOR network and not the DMX network setup. I know Matt ignores any network protocol setup in S3, just uses the Regular and AUX "x" networks you setup in the LMS file
-
First of all THANKS! for your time in creating and updating X-Lights, with out it I would not have had a 2011 show. Now on to your question:
1- 5 don't apply to me so no interest there.
6. Sound Interesting, not sure if I would use it but would be nice to have.
7. Definitely Yes, since older version of X-Lights work, those that still use LOR/Dlight protocol can use the previous version.
8,9,10 and 11 are all a yes for me.
-
My preferences:
*Mac version -- I was the big complainer about a universal PPC/Intel version (I think), but that was back a while (maybe before July 2010?). Subsequently, I have begun the Great Migration away from PPC to Intel, so I'm less of a bigot these days. If you've got a bug that you can't solve in a universal version, then I guess I'm not going to be pushed out of shape by an Intel-only version (but I still have 10 G4-based machines around, versus only one Pentium,).
*As I posted previously, I'd like a more sophisticated scheduler, which works off a calendar rather than days of the week. As I said earlier, I'd have to think there is some example code floating around the 'Net that could point you in the right direction.
*I'd really like to be able to keep the audio files and the sequence files in their native Vixen locations. I have so little disk space on my Pentium that I can't have duplicates of the audio files, so to go back to V to rework a sequence, I have to move all the audio back, do my fixes, and then move the audio again. PITA.
Thanks for all your hard work on xLights -- since my copy V refused to run the scheduler this season, if it hadn't been for xLights I wouldn't have had a show. Much appreciated.
\dmc
-
9,10,3 and 11 in that order would be at the top of my list!
-
10) Display real channel names in the Tester, instead of "Channel 123".
Sorting, grouping and filtering by channel names to be able work with groups for testing. Maybe take the channel groups and sort orders from vixen.
Absolutely - save selection to file(s) for later use.
3) Merge the Scheduler and Tester programs so that you can run tests while your show is waiting to run (currently you have to exit the scheduler to run tests).
4) Create an iPhone/iPad/iPod touch version of the Tester program. This would be E1.31 ONLY - so only compatible with the Etherdongle, ECG devices, and some of the projects on DIYC.
Thanks for a great program!
-Paul
-
9, 10 and 2 (Ubuntu 11.10) for me. Also would like you to give DJ at LSp enought info so he could export directly to Xlights.
-
I would recommend refinement in usability. Some of these new wiz bang features are nice, but I think we all seen what happens when these new toys get in front of what's really high on most people priority list. "LSP comes to mind".
I think xLights niche is being a stable, flexible show player and scheduler. I'd like to see more refinement in usability around the scheduler and player.
-
I believe in the video RJ talked about the conductor he mentioned ha gave the conductor info to LSP developer already but it still is good to have backup plans if the conductor isn't released, hardware failure, ect. Xlights helped me have a show due to LSP scheduler problems.
-
I'll second what Jeffl just said.
Stay really good at what you do, but don't try to do too much.
-
One feature I'd "LOVE" to see in the xlights scheduler is the ability to set the in and out points for each sequence in the show.
Why you might ask? So you can create quick short shows. You pick the best section of a sequence and set them in the order you want and presto, a short show. Great when it gets busy and you need to move traffic along.
Sent from my iPad using Tapatalk
-
I'm not sure I'm following that last request, but it did make me think about another nice capability.
It would be cool to be able to assign a number to each sequence in a playlist. Lets just say 1-9 for discussion.
Lets also say there is a default 'threshold' number, which allows all sequences with a that number or less to play.
So say the default threshold is 9 ... so in other words, play every song.
But you enter a lower threshold during playback, which would alter the sequences to be included going forward.
When the crowds subside, you would enter 9 again.
You could even schedule the same playlist with a different default threshold during your know peak hours if you wanted.
For example: playlist A with 9 songs ... you assign the best songs to have threshold 3, next 3 to have 6 and all others (last 3) with 9.
THen you sechedule your first hour of the day to run using 9 on playlist A, then scheduled playlist A to run with 6 threshold for next hour, then during your peak hour, you adjust down to playlist A with threshold 3 ... then back to playlist A with threshold 9 from 9pm on.
Again, just saying this would be one way to make a playlist fairly tweakable, without having to make lots of playlists ... and could also give an ability to adhoc a single number to xlights to handle traffic situations easily.
Just a thought.
-
That sounds interesting as well.
What I was getting to was this. You set the start and endpoints for each song, i.e., start plating at time index 1:23.15 end at time index 2:15.25 so you end upmarket playing 52.1 seconds of the song. If you don't put in a start or and the whole song is played. You get you times from your sequencer.
This allows for a short show keeping all the songs without resequencing them. May need to add a little fade in and out for better sound and I haven't thought about handling video.
IMHO
John
Sent from my iPad using Tapatalk
-
Thats a cool idea. It doesn't apply to me, since I already sequence shortened versions to begin with. For me, I'd have almost nothing I could cut out in the middle and have it sound good. I know others sequences a lot longer stuff with some breaks in the music which would allow this.
-
Thank you everyone for your thoughtful feedback! There are lots of good ideas here that I will try to incorporate. I am going to make as many changes as I can with current LOR and D-Light support and release that (version 2012b, release date tbd). Then I will start with the changes to the scheduler such that it runs with xLights xseq format support only (version 2012c and later).
I have already incorporated the following changes (they will be part of 2012b):
1) Merged xTester into xScheduler so that you can run tests without having to stop the schedule.
2) Calendar based scheduler (instead of weekday based) - so you can schedule special run times for Christmas Eve, run different shows on alternating days, etc.
3) Some user interface enhancements, as requested.
4) E1.31 bug fix, where some DIYC E1.31 projects were not running with xLights.
More to come!
Matt
-
Awesome news! Thanks for all of your hard work Matt. <res. I look forward to giving it a run! <pop..
-
Hi Matt
Looks great.
I did notice a difference using 2011e and 2012a when sending a pattern or test to the etherdongle and ss nodes. With 2011e it was solid and when using the same pattern xseq file it would flash with 2012a.
Rick R.
-
Thanks Matt ... sounds great !!!
Scott
-
Then I will start with the changes to the scheduler such that it runs with xLights xseq format support only (version 2012c and later).
Matt:
Thanks for all your hard work.
If the scheduler will only run the xseq format in the future, can I ask that you provide the ability to convert Vixen 2.5.x version sequences to xseq? Though one can convert 2.5 sequences into 2.1 sequences, it is a complex process that requires renaming of directories and wouldn't be easy in a production environment.
Again, thanks.
\dmc
-
Feedback:
-----
---
11) Create a program to display, and possibly make simple modifications to, an xLights sequence file.
----> yes! Esp if you are going to require that ppl convert lor and vixen to xlights. In addition, I like the visualization in the sequencer. I can run it in lor or vixen, but if forced to convert I now have to make any/ all changes in another prog and reconvert. Seems like a natural progression down the road.
-------
4) Create an iPhone/iPad/iPod touch version of the Tester program. This would be E1.31 ONLY - so only compatible with the Etherdongle, ECG devices, and some of the projects on DIYC.
--> I would love an ipad / iphone app
---
3) Merge the Scheduler and Tester programs so that you can run tests while your show is waiting to run (currently you have to exit the scheduler to run tests).
--> This seems like a good idea
---
7) Since LOR controllers, and now D-Light controllers, speak DMX, I would like to remove support for the LOR and D-Light protocols. People with these controllers would have to run them in DMX mode. Even though people might bemoan the lack of flexibility, I think they will really like the improved responsiveness (i.e. no lag) in their shows. Secondly, if we take this step, then I can simplify the scheduler to only play xLights sequence files. LOR and Vixen sequences would need to be run through the xLights converter. This would make the xLights coding much simpler (I vote for this one :) )
--> In theory, I like the idea of simplification and speed. BUT, I can imagine there will be some conversion issues that will plague many users. Sounds like it may create a headache but for speed maybe its necessary.
-----
10) Display real channel names in the Tester, instead of "Channel 123".
--> Definitely